高并發(fā)系統(tǒng)性能優(yōu)化及其在電子資料平臺中的應(yīng)用

張淼鑫, 任新會, 黨蘭學(xué), 侯彥娥

(1.河南大學(xué) 計(jì)算機(jī)與信息工程學(xué)院, 河南 開封 475004; 2.河南大學(xué) 教務(wù)處,河南 開封 475004)

0 引言

從小型門戶網(wǎng)站、聊天系統(tǒng),到大型的“12306”購票系統(tǒng)和“雙十一”電商的秒殺系統(tǒng),都體現(xiàn)了高并發(fā)系統(tǒng)的迫切需求。除了“雙十一”不斷刷新的交易記錄外,另一個(gè)重要看點(diǎn)是各大電商平臺如何處理峰值時(shí)刻的高并發(fā)情況[1-2]。許多用戶都曾遭遇“系統(tǒng)繁忙”這類異常,說明高并發(fā)技術(shù)仍然面臨挑戰(zhàn),具有相當(dāng)大的提升空間。同樣,電子資料平臺也會面臨各種高并發(fā)場景。例如,隨著在線學(xué)習(xí)的普及,當(dāng)老師在某一時(shí)間吸引大量學(xué)生時(shí),學(xué)生們需要同時(shí)訪問不同的課程材料、教科書或講義,這就構(gòu)成了大規(guī)模的高并發(fā)讀取場景[3]。

早期典型的架構(gòu)設(shè)計(jì)基于經(jīng)典的技術(shù)棧進(jìn)行開發(fā),但是因?yàn)槿狈δK化設(shè)計(jì),受單機(jī)性能制約較大,導(dǎo)致高并發(fā)的處理性能較差[4]。隨著硬件性能的大幅提升,在對單機(jī)進(jìn)行最優(yōu)設(shè)計(jì)的前提下,目前架構(gòu)設(shè)計(jì)普遍采取的方法是對系統(tǒng)進(jìn)行橫向擴(kuò)展,搭建服務(wù)器集群,對合法的請求進(jìn)行分流,并通過使用消息隊(duì)列對請求進(jìn)行“削峰填谷”的處理。為使數(shù)據(jù)庫穩(wěn)定地處理這些請求,往往利用緩存中間件減少對數(shù)據(jù)庫的訪問,并通過服務(wù)降級,減輕峰值期間的訪問壓力[5-6]。本文基于多級緩存、熱點(diǎn)探測、分布式鎖、分布式事務(wù)等技術(shù),設(shè)計(jì)了一套高并發(fā)解決方案,并將該方案應(yīng)用于電子資料系統(tǒng)進(jìn)行測試。測試結(jié)果表明,該方案可為電子資料系統(tǒng)提供卓越的穩(wěn)定性和可擴(kuò)展性。

1 技術(shù)原理和系統(tǒng)總體架構(gòu)設(shè)計(jì)

本文設(shè)計(jì)的高并發(fā)電子資料平臺,主要支持文檔收集、整理、檢索、共享、閱讀、下載、統(tǒng)計(jì)分析等主要功能,以及人員信息維護(hù)、部門信息維護(hù)、權(quán)限維護(hù)等輔助的系統(tǒng)功能。系統(tǒng)架構(gòu)如圖1所示,核心組成部分包括文檔管理模塊、檢索與查詢模塊、共享與權(quán)限模塊、用戶管理模塊、數(shù)據(jù)統(tǒng)計(jì)與分析模塊。為支持高并發(fā)和大規(guī)模數(shù)據(jù)處理,系統(tǒng)引入了多級緩存,包括本地緩存、分布式緩存等,以減輕數(shù)據(jù)庫負(fù)載;采用熱點(diǎn)探測算法,以識別熱門文檔,減少系統(tǒng)瓶頸;使用分布式數(shù)據(jù)庫和分布式事務(wù)處理,以確保數(shù)據(jù)的一致性和可靠性; 應(yīng)用分布式鎖機(jī)制,以協(xié)調(diào)多個(gè)并發(fā)操作,避免數(shù)據(jù)沖突。

圖1 系統(tǒng)架構(gòu)

2 高并發(fā)系統(tǒng)的實(shí)現(xiàn)

2.1 多級緩存與熱點(diǎn)數(shù)據(jù)的處理

目前在高并發(fā)架構(gòu)中使用較多的是分布式緩存,但是數(shù)據(jù)需要從遠(yuǎn)程緩存中獲取,導(dǎo)致吞吐量下降,所以本系統(tǒng)使用的是多級緩存[7]。多級緩存主要分為3層,Nginx應(yīng)用層緩存,Redis分布式緩存以及Tomcat的堆內(nèi)緩存。緩存流程如圖2所示。

圖2 多級緩存流程圖

Nginx集群分為接入和應(yīng)用兩種,通過接入Nginx將請求分發(fā)到應(yīng)用Nginx。為了提升緩存的命中率,這里的負(fù)載均衡算法在正常情況下采用的是一致性哈希算法,但是如果訪問量到達(dá)了極限,就降級為輪詢算法。接著在應(yīng)用Nginx中讀取本地緩存,本地緩存用Lua Shared Dict實(shí)現(xiàn),并結(jié)合頁面模板生成頁面。如果Nginx本地緩存已經(jīng)過期,那么系統(tǒng)將嘗試從Redis中獲取,同時(shí)更新Nginx的本地緩存。如果Redis中的數(shù)據(jù)被LRU(least recently used)算法清理掉,那么系統(tǒng)將發(fā)出HTTP(hypertext transfer protocol)請求到后端服務(wù),數(shù)據(jù)生成服務(wù)首先在本地Tomcat的JVM(Java virtual machine)堆棧內(nèi)存中查找,使用Ehcache緩存。如果JVM堆棧內(nèi)存中的數(shù)據(jù)也被LRU清理掉,那么系統(tǒng)將重新請求源頭服務(wù)以獲取數(shù)據(jù),然后再次更新Tomcat堆內(nèi)存緩存和Redis緩存,并將數(shù)據(jù)返回給Nginx,Nginx再將數(shù)據(jù)緩存到本地。其中各級緩存的目標(biāo)不同,由于Nginx本地緩存的容量有限,所以該級緩存用于支持對熱點(diǎn)數(shù)據(jù)的高并發(fā)訪問;Redis分布式緩存容量很大,可以支持海量的緩存數(shù)據(jù),所以重點(diǎn)針對高離散數(shù)據(jù)的訪問;最后一級Tomcat堆內(nèi)緩存,主要用于對抗Redis大規(guī)模宕機(jī),大量請求涌入數(shù)據(jù)生產(chǎn)服務(wù)時(shí)產(chǎn)生的壓力。

系統(tǒng)除了要處理一些常用的熱點(diǎn)數(shù)據(jù)之外,更重要的是要處理特殊場合出現(xiàn)的熱點(diǎn)數(shù)據(jù)。常見的熱點(diǎn)數(shù)據(jù)會被提前放入多級緩存,特殊的數(shù)據(jù)一般要通過分析、計(jì)算,在Nginx緩存層進(jìn)行處理,即對熱點(diǎn)數(shù)據(jù)的實(shí)時(shí)監(jiān)測和追蹤。對于熱點(diǎn)數(shù)據(jù)的監(jiān)測,可以使用數(shù)據(jù)調(diào)研,對歷史數(shù)據(jù)進(jìn)行分析做出策略,但是這種方法的緩存命中率并不能達(dá)到100%[8]。本文使用實(shí)時(shí)計(jì)算對熱點(diǎn)數(shù)據(jù)進(jìn)行監(jiān)測,如圖2所示。Flume框架主要用于海量數(shù)據(jù)聚合,Flink框架在集群環(huán)境中對有邊界或者無邊界的數(shù)據(jù)流進(jìn)行計(jì)算,可對Flume采集的Nginx層日志信息處理分析。用Flume直接對接實(shí)時(shí)計(jì)算框架,如果數(shù)據(jù)采集速度遠(yuǎn)大于處理速度的話,會造成消息丟失或堆積,所以在它們之間引入消息中間件,不僅可在業(yè)務(wù)邏輯上進(jìn)行解耦,而且相當(dāng)于對數(shù)據(jù)進(jìn)行了分桶處理,進(jìn)行數(shù)據(jù)隔離。這里集成Flume和Kafka完成日志處理,隨后使用Flink實(shí)時(shí)處理技術(shù),統(tǒng)計(jì)某一時(shí)間內(nèi)的文件訪問量、點(diǎn)擊率,從而實(shí)現(xiàn)目標(biāo)的解析——將某一時(shí)刻訪問量大的實(shí)體數(shù)據(jù)標(biāo)識為熱點(diǎn)數(shù)據(jù)。當(dāng)這些數(shù)據(jù)被識別出來后,根據(jù)數(shù)據(jù)自身的特點(diǎn)將其放入多級緩存的各個(gè)節(jié)點(diǎn)。除此之外,為應(yīng)對大流量的沖擊,需要對Tomcat集群,也就是該數(shù)據(jù)所對應(yīng)的業(yè)務(wù)處理服務(wù)進(jìn)行擴(kuò)充。本系統(tǒng)使用Kubernetes,程序自動(dòng)調(diào)整參數(shù)值,對其相關(guān)服務(wù)擴(kuò)容。

2.2 分布式鎖

高并發(fā)系統(tǒng)中另一個(gè)重要的問題,是多線程場景下對并發(fā)數(shù)據(jù)進(jìn)行更改和讀取。在“先更新數(shù)據(jù)庫、再更新緩存”的設(shè)計(jì)方案中,存在兩個(gè)線程,即線程 A 和線程 B,它們同時(shí)操作同一條數(shù)據(jù)時(shí)可能出現(xiàn)以下情況:線程 A 更新數(shù)據(jù)庫(X=1),線程 B 更新數(shù)據(jù)庫(X=2),接著線程B更新了緩存(X=2),而線程 A 也更新了緩存(X=1)。最終在緩存中的值為1,而在數(shù)據(jù)庫中的值為2,導(dǎo)致數(shù)據(jù)不一致。同樣,使用“先更新緩存,再更新數(shù)據(jù)庫”的方法也可能面臨類似的問題。本系統(tǒng)通過加分布式鎖解決此問題。傳統(tǒng)的設(shè)計(jì)方案是用MySQL做分布式鎖,但是MySQL做鎖時(shí)要讀取磁盤IO(input output),當(dāng)訪問量較大時(shí),系統(tǒng)性能會比較低,所以本系統(tǒng)使用Redis作為分布式鎖[9]。

結(jié)合業(yè)務(wù)流程設(shè)置分布式鎖,將Redis的相關(guān)節(jié)點(diǎn)傳入對象,調(diào)用該對象的trylock(waitTime, leaseTime, unit)對其加鎖,其中waitTime代表請求鎖的等待時(shí)間,leaseTime代表鎖的有效期,unit 代表時(shí)間單位。以下為嘗試獲取鎖的偽代碼示例:

Public boolean trylock(waitTime, leaseTime, unit){

newLeaseTime = getLeaseMillis(leaseTime);

remainTime = getRemainMillis(waitTime);

lockWaitTime = calcLockWaitTime(remainTime);//每個(gè)等待實(shí)例時(shí)間與1比較取最大值

failedLocksLimit = failedLocksLimit();//允許獲取鎖失敗的次數(shù)

for(ListIterator iterator = locks.listIterator()){//循環(huán)每個(gè)redis客戶端去獲取鎖

lockAcquired = lock.tryLock();

If(lockAcquired)

acquiredLocks.add(lock);//獲取到該鎖了,加入隊(duì)列

failedLocksLimt = failedLocksLimit();//獲取鎖失敗重試機(jī)制

}

rFuture.syncUninterruptibly();//key過期后用中斷方式釋放期鎖

}

算法依次在N個(gè)實(shí)例上嘗試獲取鎖,使用相同的鍵(key)和隨機(jī)值,當(dāng)客戶端將鎖設(shè)置到Redis時(shí),再設(shè)定網(wǎng)絡(luò)連接和響應(yīng)的超時(shí)時(shí)間。超時(shí)時(shí)間應(yīng)短于鎖的自動(dòng)失效時(shí)間,以避免客戶端陷入等待服務(wù)器端Redis響應(yīng)的情況(即使服務(wù)器端的Redis已經(jīng)失效)。如果服務(wù)器端未在規(guī)定時(shí)間內(nèi)響應(yīng),客戶端應(yīng)該盡快嘗試另一個(gè)Redis實(shí)例?？蛻舳丝梢酝ㄟ^將當(dāng)前時(shí)間減去獲取鎖時(shí)的起始時(shí)間,計(jì)算獲取鎖所用的時(shí)間。只有當(dāng)超過一半的Redis節(jié)點(diǎn)成功獲取了鎖,并且所用時(shí)間短于鎖的失效時(shí)間時(shí),才被認(rèn)為成功獲取了鎖。如果成功獲取了鎖,那么鍵的實(shí)際有效時(shí)間則等于有效時(shí)間減去獲取鎖所用的時(shí)間;如果由于某些原因未能成功獲取鎖,在至少N/2+1個(gè)Redis實(shí)例中未能獲取鎖,或者獲取鎖所用時(shí)間已經(jīng)超過了有效時(shí)間,則客戶端應(yīng)該在所有Redis實(shí)例上執(zhí)行解鎖操作(即使在某些Redis實(shí)例上根本沒有成功加鎖)。圖3是加鎖過程的流程圖。

圖3 加鎖流程圖

2.3 分布式事務(wù)

分布式文件系統(tǒng)中的一種數(shù)據(jù)操作過程,其中一個(gè)請求可能需要調(diào)用多個(gè)服務(wù),并在這些服務(wù)中的每一個(gè)都連接到各自的數(shù)據(jù)庫。所以當(dāng)其中某一個(gè)事務(wù)執(zhí)行失敗,就會出現(xiàn)數(shù)據(jù)不一致的問題。傳統(tǒng)的解決方發(fā)是采用“兩階段”提交 ,但是“兩階段”提交中只有協(xié)調(diào)者設(shè)置了超時(shí)機(jī)制,而參與者沒有設(shè)置,所以當(dāng)協(xié)調(diào)者宕機(jī),接受消息的參與者也宕機(jī)時(shí),事務(wù)的狀態(tài)就不確定了[10]。所以本系統(tǒng)使用的是“三階段”提交,在參與者中也引入超時(shí)機(jī)制,并且在第一階段和第二階段之間引入一個(gè)中間狀態(tài)解決該問題,圖4是“三階段”提交的狀態(tài)機(jī)。

圖4 “三階段”狀態(tài)機(jī)

這里將提交分為3個(gè)階段:①CanCommit,②PreCommit,③DoCommit;角色為協(xié)調(diào)者和參與者。在CanCommit階段,協(xié)調(diào)者開始寫本地日志,進(jìn)入WAIT狀態(tài),同時(shí)向參與者發(fā)送VOTE_REQUEST消息并等待參與者的響應(yīng),參與者會響應(yīng)VOTE_ABORT或者VOTE_COMMIT消息。在PreCommit階段,協(xié)調(diào)者會通知參與者準(zhǔn)備提交或者取消事務(wù),并寫REDO和UNDO日志,但不做提交。此時(shí)如果協(xié)調(diào)者接收到參與者的VOTE_ABORT消息,會寫GLOBAL_ABORT日志,進(jìn)入ABORT狀態(tài),并向參與者發(fā)送GLOBAL_ABORT消息。如果收到的是參與者發(fā)送的VOTE_COMMIT消息,協(xié)調(diào)者將會寫PREPARE_COMMIT日志,并進(jìn)入PRECOMMIT狀態(tài),再向所有的參與者發(fā)送PREPARE_COMMIT消息,之后等待并接收確認(rèn)消息,一旦收到GLOBAL_ABORT,則寫日志流程結(jié)束,不進(jìn)入下一階段,如果收到PREPARE_COMMIT,則進(jìn)入DoCommit階段。該階段協(xié)調(diào)者會向所有的參與者發(fā)送GLOBAL_COMMIT消息,并接收參與者的GLOBAL_COMMIT確認(rèn)消息,寫END_TRANSACTION日志流程結(jié)束,如果其中參與者無法接收到來自協(xié)調(diào)者的請求,會在超時(shí)等待后,繼續(xù)進(jìn)行任務(wù)提交。

3 系統(tǒng)性能測試

將本文設(shè)計(jì)的高并發(fā)解決方案應(yīng)用于電子資料系統(tǒng),并使用JMeter執(zhí)行教學(xué)資源訪問的性能負(fù)載測試,通過逐漸增加每秒并發(fā)請求數(shù),評估系統(tǒng)的整體性能。結(jié)果發(fā)現(xiàn),在不同請求數(shù)量的并發(fā)負(fù)載下,系統(tǒng)始終保持相對穩(wěn)定,具有良好的穩(wěn)定性和準(zhǔn)確性。表1是不同并發(fā)數(shù)的系統(tǒng)性能測試數(shù)據(jù),通信消耗時(shí)間約為2 ms,即使在有10 000個(gè)并發(fā)訪問時(shí),服務(wù)調(diào)用時(shí)間的平均值也保持在300 ms以下。隨著并發(fā)量的增加,系統(tǒng)沒有出現(xiàn)任務(wù)異常,可見該高并發(fā)設(shè)計(jì)解決方案在處理大流量式數(shù)據(jù)時(shí),在數(shù)據(jù)處理平均耗時(shí)和延遲時(shí)間等方面表現(xiàn)出了理想的性能。這一性能表現(xiàn)可以滿足大部分企業(yè)的數(shù)據(jù)處理需求。

表1 系統(tǒng)性能測試表

4 結(jié)束語

高并發(fā)讀寫場景的有效處理是一項(xiàng)具有挑戰(zhàn)性的任務(wù),對于在線教學(xué)至關(guān)重要。通過合適的系統(tǒng)設(shè)計(jì)和技術(shù)選擇,能夠確保系統(tǒng)穩(wěn)定處理大規(guī)模的并發(fā)請求,在電子教學(xué)資料系統(tǒng)中提供高效的教學(xué)資源訪問,為學(xué)生和教育工作者提供良好的學(xué)習(xí)和教學(xué)體驗(yàn)。需要綜合考慮緩存、負(fù)載均衡、數(shù)據(jù)庫優(yōu)化、CDN(content delivery network)等策略,以確保系統(tǒng)性能和數(shù)據(jù)一致性,為在線教學(xué)提供更多便利。