林平榮，陳澤榮，施曉權(quán)

(1.廣州大學(xué)華軟軟件學(xué)院 軟件研究所，廣東 廣州 510990； 2.華南理工大學(xué) 計算機科學(xué)與工程學(xué)院，廣東 廣州 510006)

0 引 言

隨著互聯(lián)網(wǎng)的快速發(fā)展和線上用戶的急劇增加，高并發(fā)請求產(chǎn)生的多線程競爭共享資源系統(tǒng)面臨著更大的挑戰(zhàn)。高并發(fā)是一種系統(tǒng)運行過程中出現(xiàn)同時并行處理大量用戶請求的現(xiàn)象。多線程競爭共享資源指的是在高并發(fā)場景下，多個請求產(chǎn)生多個線程，從而造成多個線程同時競爭訪問共享資源。共享資源應(yīng)用對象可以是火車票或商品等有限數(shù)量資源，典型的場景有“12306搶火車票”、“天貓雙十一秒殺活動”等。由于并發(fā)訪問數(shù)量多且共享資源有限，因此對系統(tǒng)的并發(fā)性能以及資源一致性有更高的要求。

經(jīng)過查閱相關(guān)文獻，目前已有大量解決Web系統(tǒng)性能難題的方案[1-9]被提出，解決方案主要圍繞以下幾個方面：負載均衡[5]、數(shù)據(jù)緩存[6,9]、數(shù)據(jù)庫優(yōu)化[7]以及Web前端優(yōu)化[8]。雖然這些方案在一定程度上可以提高系統(tǒng)性能，但考慮的點比較單一，并沒有過多提及多線程競爭共享資源時系統(tǒng)垂直或水平擴展下如何確保資源的安全性和一致性?；诖?，本文將從多方面綜合考慮，基于數(shù)據(jù)緩存、分布式鎖、消息隊列、負載均衡4個方面進行詳細的分析與研究，提出一種適合高并發(fā)多線程競爭共享資源應(yīng)用場景的高性能通用系統(tǒng)架構(gòu)。

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

系統(tǒng)架構(gòu)分為訪問層、應(yīng)用層、存儲層。訪問層用于Web接入、反向代理、負載均衡等；應(yīng)用層用于核心業(yè)務(wù)服務(wù)模塊處理，具備服務(wù)治理、調(diào)度、異步通信等核心服務(wù)能力；存儲層進行最終數(shù)據(jù)的落地及提供數(shù)據(jù)的能力。架構(gòu)如圖1所示。

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

架構(gòu)部署后，應(yīng)用服務(wù)器先從數(shù)據(jù)庫服務(wù)器將高并發(fā)請求中頻繁訪問的數(shù)據(jù)讀取到緩存服務(wù)器中?？蛻舳说母卟l(fā)請求先由LVS(linux virtual server)在IP層均衡地轉(zhuǎn)發(fā)到負載均衡服務(wù)器，負載均衡服務(wù)器會先將資源返回給客戶端，再將請求轉(zhuǎn)發(fā)到應(yīng)用服務(wù)器。應(yīng)用服務(wù)器接收到請求時，在一定時間內(nèi)不斷嘗試從分布式緩存服務(wù)器中獲取鎖的操作，獲取成功則會進行相應(yīng)的業(yè)務(wù)邏輯處理。在緩存服務(wù)器中進行數(shù)據(jù)的增刪改查并將數(shù)據(jù)發(fā)送到消息隊列服務(wù)器中，最后由消費者進行消息監(jiān)聽，將數(shù)據(jù)同步到數(shù)據(jù)庫服務(wù)器中，實現(xiàn)數(shù)據(jù)異步更新。

架構(gòu)設(shè)計秉持“冗余”+“主動故障轉(zhuǎn)移”兩個原則，“冗余”是為了解決單一節(jié)點出現(xiàn)故障而backup節(jié)點能夠繼續(xù)提供服務(wù)，而主動故障轉(zhuǎn)移是探測到故障的發(fā)生則自動進行轉(zhuǎn)移，將故障節(jié)點流量進行引流。架構(gòu)的設(shè)計從業(yè)務(wù)的角度出發(fā)，第一是純靜態(tài)資源的請求，另外一個是涉及業(yè)務(wù)處理的請求。

純靜態(tài)資源請求的處理：前端固化頁面展示采用靜態(tài)化的思想，將Redis緩存數(shù)據(jù)填充靜態(tài)模板中，形成靜態(tài)化頁面，再推送到Nginx服務(wù)器中，當客戶端訪問請求時，LVS均衡地在IP層轉(zhuǎn)發(fā)至處理服務(wù)的Nginx，從負載的Nginx直接返回沒有涉及業(yè)務(wù)邏輯處理的靜態(tài)頁面，減少與數(shù)據(jù)庫服務(wù)交互的次數(shù)，且不執(zhí)行任何代碼，給予客戶端較快的響應(yīng)速度。當頁面數(shù)據(jù)發(fā)生變更時，會觸發(fā)監(jiān)聽器將變更的消息壓入消息隊列中，緩存服務(wù)感知數(shù)據(jù)變更，便會調(diào)用數(shù)據(jù)服務(wù)，將整理好數(shù)據(jù)重新推送至Redis中，更新Nginx頁面。Nginx本地緩存數(shù)據(jù)也是有一定的時限，為了避免頁面的集中獲取，采用隨機散列的策略來規(guī)避。

涉及業(yè)務(wù)請求的處理：倘若LVS負載均衡分配Nginx的高并發(fā)請求是攜帶業(yè)務(wù)性的，就會導(dǎo)致多線程競爭共享資源時數(shù)據(jù)不一致的窘境。為避免這種問題，采取Redis分布式鎖的方式以維護共享資源的數(shù)據(jù)一致和安全問題，然后再將操作后的相關(guān)緩存數(shù)據(jù)寫入消息隊列服務(wù)器中，最后交由消費者進行監(jiān)聽消費，這樣的異步設(shè)計是為了實現(xiàn)緩存與數(shù)據(jù)庫的互通，逐級削減對數(shù)據(jù)庫服務(wù)器的訪問。此外，為了維護緩存和數(shù)據(jù)庫的雙寫一致性，堅持“Cache Aside Pattern”原則。

設(shè)計過程中，盡量考慮到分布式緩存服務(wù)和消息隊列服務(wù)在生產(chǎn)環(huán)境會產(chǎn)生的細節(jié)問題，針對所在問題依次采取下列措施：

(1)在分布式緩存服務(wù)中，考慮緩存應(yīng)用于高并發(fā)場景易發(fā)生的雪崩、穿透和擊穿情況，分別提供相對應(yīng)的方案如下：

緩存雪崩情況，分別在緩存雪崩前中后的各時間段，依據(jù)業(yè)務(wù)設(shè)計相應(yīng)的解決方案：

1)在事前：利用Redis高可用的主從+哨兵的Redis Cluster避免全盤崩潰；

2)在事中：采用本地緩存+Nginx限流，避免數(shù)據(jù)庫壓力過大；

3)在事后：Redis開啟持久化，一旦重啟，自動加載磁盤數(shù)據(jù)，快速恢復(fù)數(shù)據(jù)。

緩存穿透是高并發(fā)請求的目標數(shù)據(jù)都不在緩存與數(shù)據(jù)庫的情況，易導(dǎo)致數(shù)據(jù)庫的直接崩盤，該情況采取Set -999 UNKNOWN，盡量設(shè)置有效期，避免下次訪問直接從緩存獲取。為了防止緩存擊穿，可采取一些熱點數(shù)據(jù)嘗試設(shè)置永不過期。

(2)在消息隊列服務(wù)中，共享資源的最終持久化是在消息隊列服務(wù)中進行的，為了維護共享資源的最終一致性，考慮寫入消息隊列服務(wù)器中消息的消費冪等性、可靠性傳輸、消費順序性和容器飽滿的情況，檢查數(shù)據(jù)庫主鍵的唯一性來確保消費的冪等性，避免重復(fù)消費的請求；消息隊列的可靠性傳輸，在生產(chǎn)者設(shè)置Ack響應(yīng)，要求leader接收到消息之后，所有的follower必須進行同步的確認寫入成功，如果沒有滿足該條件，生產(chǎn)者會自動不斷地重試。為了避免中間件消息隊列自己丟失數(shù)據(jù)，必須開啟持久化功能；消息隊列的順序消費，采取一個queue對應(yīng)一個consumer，然后這個consumer內(nèi)部采用內(nèi)存隊列做排隊，分發(fā)給底層不同的worker來處理；消息隊列容器飽滿時，將會觸發(fā)待命的臨時程序加入消費的行列中，加快消費速度，以免消息溢出的慘狀。

2 關(guān)鍵技術(shù)

2.1 數(shù)據(jù)緩存

現(xiàn)代Web系統(tǒng)一般都會采用緩存策略對直接進行數(shù)據(jù)庫讀寫的傳統(tǒng)數(shù)據(jù)操作方式進行改進。緩存大致主要分為兩種：頁面緩存和數(shù)據(jù)緩存。架構(gòu)基于Redis集群實現(xiàn)數(shù)據(jù)緩存，具有故障容錯等功能。Redis完全基于內(nèi)存，通過Key-Value存儲能獲得良好的性能，尤其表現(xiàn)在良好的并行讀寫性能[10]。由于投票容錯機制要求超過半數(shù)節(jié)點認為某個節(jié)點出現(xiàn)故障才會確定該節(jié)點下線，因此Redis集群至少需要3個節(jié)點，為了保證集群的高可用性，每個主節(jié)點都有從節(jié)點。實現(xiàn)Redis集群拓撲結(jié)構(gòu)如圖2所示。

圖2 Redis集群網(wǎng)絡(luò)拓撲

Redis集群由6臺服務(wù)器搭建，分別由3個主節(jié)點和3個從節(jié)點組成，數(shù)據(jù)都是以Key-Value形式存儲，不同分區(qū)的數(shù)據(jù)存放在不同的節(jié)點上，類似于哈希表的結(jié)構(gòu)。使用哈希算法將Key映射到0-16383范圍的整數(shù)，一定范圍內(nèi)的整數(shù)對應(yīng)的抽象存儲稱為槽，每個節(jié)點負責一定范圍內(nèi)的槽，槽范圍如圖3所示。

圖3 槽范圍

集群啟動時，會先從數(shù)據(jù)庫服務(wù)器讀取高并發(fā)請求中頻繁訪問的數(shù)據(jù)，其中包括共享資源數(shù)據(jù)，將數(shù)據(jù)轉(zhuǎn)換為JSON數(shù)據(jù)格式或?qū)ο笮蛄谢跏蓟絉edis服務(wù)器中，數(shù)據(jù)會根據(jù)哈希算法新增到對應(yīng)的節(jié)點中。應(yīng)用服務(wù)器接收到高并發(fā)請求進行數(shù)據(jù)查詢、修改或刪除時，會隨機把命令發(fā)給某個節(jié)點，節(jié)點計算并查看這個key是否屬于自己的，如果是自己的就進行處理，并將結(jié)果返回，如果是其它節(jié)點的，會把對應(yīng)節(jié)點信息(IP+地址)轉(zhuǎn)發(fā)給應(yīng)用服務(wù)器，讓應(yīng)用服務(wù)器重定向訪問。Redis返回結(jié)果后，應(yīng)用服務(wù)器會將數(shù)據(jù)發(fā)送到消息隊列服務(wù)器中，并立即將返回結(jié)果給客戶端。

2.2 分布式鎖

在分布式系統(tǒng)中，共享資源可能被多個競爭者同時請求訪問，往往會面臨數(shù)據(jù)的一致性問題[11]，因此必須保證資源數(shù)據(jù)訪問的正確性和性能。架構(gòu)使用分布式鎖的方式解決該問題。分布式架構(gòu)下的開源組件很多，如Zookee-per、Redis、Hbase等，相比之下，Redis的性能與成熟度較高。指定一臺Redis服務(wù)器作為鎖的操作節(jié)點，保證獲取鎖的操作是原子性的。Redis本身是單線程程序，可以保證對緩存數(shù)據(jù)操作都是線程安全的。當應(yīng)用服務(wù)器集群接收到高并發(fā)產(chǎn)生的多線程同時請求訪問共享資源時，線程必須先從Redis服務(wù)器中獲取鎖，使用setnx指令獲取鎖成功后，其余的線程請求獲取鎖的操作會返回失敗，返回失敗后的線程在一定時間內(nèi)不斷重試獲取鎖，只有等待已獲取鎖的線程執(zhí)行成功后釋放鎖，才能讓下一個線程獲取鎖后訪問共享資源。線程獲取鎖成功后，若有線程報錯會中途退出，獲取鎖之后沒有釋放，就會造成死鎖。使用expire作為默認過期時間，如果線程獲取鎖后超過默認過期時間，則鎖會自動釋放，為了避免業(yè)務(wù)邏輯處理報錯，導(dǎo)致線程中途退出，因此需要再加上捕獲異常處理塊。示例代碼如下：

//獲取lock失敗

if(!set lock true ex 5 nx)

{ return; }

try{#處理業(yè)務(wù)邏輯

……

//釋放lock

del lock }

catch(Exception ex)

{ //釋放lock

del lock }

由于采用分布式鎖，在系統(tǒng)垂直或水平擴展的情況下，保證同一時間的一個線程獲取到鎖，確保共享資源的安全性和一致性。在高并發(fā)場景下，如果有大量的線程不斷重試獲取鎖失敗的操作，會造成Redis服務(wù)器壓力過大，Redis服務(wù)器與應(yīng)用服務(wù)器之間交互流量過高。因此，在應(yīng)用系統(tǒng)上使用基于cas算法的樂觀鎖方式解決該問題。cas算法存在著3個參數(shù)，內(nèi)存值V，預(yù)期值E，更新值N。當且僅當內(nèi)存值V與預(yù)期值E相等時，才會將內(nèi)存值修改為N，否則什么也不做。借助jdk的juc類庫所提供的cas算法，以及帶有原子性的基本類型封裝類AtomicBoolean，實現(xiàn)區(qū)別于synchronized同步鎖的一種樂觀鎖，線程不會阻塞，不涉及上下文切換，具有性能開銷小等優(yōu)點。示例代碼如下：

long startTime = System.currentTimeMillis();

AtomicBoolean state=new AtomicBoolean(false);

//X秒內(nèi)不斷重試調(diào)用compareAndSet方法修改內(nèi)存

while ((startTime+X)>= System.currentTimeMillis()){

//預(yù)期值false,更新值true

if(!state.get()&&state.compareAndSet(false,true)){

//修改內(nèi)存值成功

try{

#獲取分布式鎖

…

//將內(nèi)存值重新修改為false

state.compareAndSet(true,false);

}catch(Exception ex){

state.compareAndSet(true,false);

}

}

}

各個應(yīng)用系統(tǒng)的線程通過在一定時間內(nèi)不斷重試修改內(nèi)存值，如果修改成功，才可以繼續(xù)獲取分布式鎖，以解決Redis服務(wù)器的壓力和流量問題。

2.3 消息隊列

消息隊列是一種異步傳輸模式，其主要核心優(yōu)點為以下3點：業(yè)務(wù)解耦、通信異步、流量削峰[12,13]，因此可應(yīng)用于很多高并發(fā)場景。目前主流的消息隊列中間件有Kafka、RabbitMQ、ActiveMQ及Microsoft MSMQ[12]等，其中RabbitMQ是一個開源的AMQP實現(xiàn)，支持多種客戶端，總共有6種工作模式，用于在分布式或集群系統(tǒng)中存儲轉(zhuǎn)發(fā)消息，具有較好的易用性、擴展性、高可用性。架構(gòu)使用RabbitMQ實現(xiàn)數(shù)據(jù)庫與Redis緩存數(shù)據(jù)的同步，可以根據(jù)實際高并發(fā)場景進行判斷選擇合適的通信模式以及生產(chǎn)者與消費者的對應(yīng)關(guān)系。下面以RabbitMQ的路由模式為例，具體實現(xiàn)的路由模式結(jié)構(gòu)如圖4所示。

圖4 路由模式結(jié)構(gòu)

按照實際業(yè)務(wù)，以明顯的類別劃分，聲明一個交換機，4個消息隊列，創(chuàng)建4個消費者分別監(jiān)聽4個消息隊列，應(yīng)用系統(tǒng)數(shù)量對應(yīng)生產(chǎn)者數(shù)量。當系統(tǒng)接收到高并發(fā)請求資源時，會使用Redis分布式鎖確保所有系統(tǒng)產(chǎn)生的線程同步執(zhí)行訪問共享資源，保證共享資源的安全性、一致性。釋放鎖后，再將處理完成的數(shù)據(jù)更新到Redis中，Redis返回結(jié)果后，系統(tǒng)會將數(shù)據(jù)轉(zhuǎn)化為JSON格式，按照消息路由鍵，確保同個客戶端請求的數(shù)據(jù)在同個消息隊列中，能夠在消費者進行數(shù)據(jù)增刪改時按照先后順序執(zhí)行，保證系統(tǒng)公平性。設(shè)置路由鍵后將數(shù)據(jù)發(fā)送到交換機中，交換機會根據(jù)路由規(guī)則將不同類別的數(shù)據(jù)發(fā)送到綁定的對應(yīng)消息隊列中，每個消息隊列都有對應(yīng)的一個消費者，消費者會監(jiān)聽對應(yīng)的消息隊列，監(jiān)聽到消息后會進行JSON格式數(shù)據(jù)的解析，再將數(shù)據(jù)同步到數(shù)據(jù)庫中。利用RabbitMQ消息隊列，進行強弱依賴梳理分析，將數(shù)據(jù)同步到數(shù)據(jù)庫的操作異步化，以解決數(shù)據(jù)庫的高并發(fā)壓力。

由圖1～3可知，3種水灰比的試件，經(jīng)過凍融0次、25次和50次后，其峰值應(yīng)力均隨著應(yīng)變加載速率的增加而增加。

2.4 負載均衡

應(yīng)對高并發(fā)訪問，負載均衡技術(shù)是構(gòu)建高并發(fā)Web系統(tǒng)有效的方法[14]。常用負載均衡方法有：①DNS負載均衡；②NAT負載均衡；③軟件、硬件負載均衡；④反向代理負載均衡。①方法無法獲知各服務(wù)器差異，④方法在流量過大時服務(wù)器本身容易成為瓶頸，③方法中的軟件方式是通過在服務(wù)器上安裝軟件實現(xiàn)負載均衡，如LVS、PCL-SIS等。LVS是Linux虛擬服務(wù)器，從操作系統(tǒng)層面考慮，架構(gòu)訪問層采用LVS及Nginx集群組成，分別在IP層和應(yīng)用層進行請求的負載均衡轉(zhuǎn)發(fā)。通過OSI七層模型結(jié)構(gòu)可知，在IP層實現(xiàn)請求的負載均衡比在應(yīng)用層更加高效，減少了上層的網(wǎng)絡(luò)調(diào)用及分發(fā)。架構(gòu)采用LVS的DR模式，由LVS作為系統(tǒng)整個流量的入口，采用IP負載均衡技術(shù)和基于內(nèi)容請求分發(fā)技術(shù)，將請求均衡地轉(zhuǎn)發(fā)到不同的Nginx服務(wù)器上，但是只負責接收請求，結(jié)果由Nginx服務(wù)器直接返回，避免LVS成為網(wǎng)絡(luò)流量瓶頸。由多個客戶端發(fā)送的高并發(fā)請求，會先進行DNS尋址，找到對應(yīng)機房的公網(wǎng)IP，由LVS接入，再將請求均衡的轉(zhuǎn)發(fā)到Nginx服務(wù)器，再由Nginx服務(wù)器將請求均衡的轉(zhuǎn)發(fā)到應(yīng)用服務(wù)器，有利于Nginx服務(wù)器的擴展，可將整個系統(tǒng)進行水平拓展，加入更多的硬件支持，提高并發(fā)請求的處理效率。

3 測試與分析

為了驗證架構(gòu)設(shè)計的有效性，選擇具有高并發(fā)資源競爭需求的選課場景為例，課程的額定容量就是共享資源，學(xué)生選課的過程其實就是搶占額定容量的過程。把案例分別部署在普通集群架構(gòu)和本文提出的集群架構(gòu)，基于內(nèi)網(wǎng)同個網(wǎng)段搭建實驗平臺環(huán)境。普通集群采用Nginx技術(shù)實現(xiàn)負載均衡，使用了基于表記錄的新增與刪除操作，利用字段唯一性約束的方式實現(xiàn)數(shù)據(jù)庫分布式鎖以及使用Redis實現(xiàn)會話共享?？紤]到測試的公平性以及簡化測試復(fù)雜度，保證兩個集群的物理配置以及應(yīng)用配置參數(shù)一致，其中設(shè)置Nginx主要參數(shù) keepAlivetimeout、fastcgi_connect_timeout、fastcgi_send_timeout、fastcgi_read_timeout均為8000，以服務(wù)器配置為準分配權(quán)重，設(shè)置 tomcat主要參數(shù)connectionTimeout為80 000，maxConnections為80 000，maxThreads為8000，minSpareThreads為100，maxIdleTime為6000。在測試中本文集群排除了LVS，直接以Nginx服務(wù)器作為請求負載均衡以及Redis單機方式完成整個測試流程。沒有引入LVS的原因是本次實驗是以搶課業(yè)務(wù)為測試場景，LVS的加入只是為了保障Nginx容錯性，且目前的并發(fā)數(shù)實在難以使其出現(xiàn)宕機情況，故剔除LVS的引入，選擇直接利用Nginx負載均衡、轉(zhuǎn)發(fā)的特性，對深層次的服務(wù)進行并發(fā)測試，更能獲取到架構(gòu)內(nèi)部整體的性能指標。

普通集群一共用了5個節(jié)點，其中節(jié)點2、3作為Tomcat服務(wù)節(jié)點，其余的分別為節(jié)點1(Nginx節(jié)點)、節(jié)點5(Mysql節(jié)點)、節(jié)點4(Redis節(jié)點)。本文集群與普通集群的區(qū)別是在節(jié)點4加入了RabbitMq，節(jié)點4 作為數(shù)據(jù)緩存、消息隊列和分布式鎖節(jié)點。兩個集群的各節(jié)點配置和容器版本等見表1。

表1 服務(wù)器節(jié)點配置

測試過程采用JMeter測試工具進行性能數(shù)據(jù)采集，通過不斷調(diào)高并發(fā)數(shù)量得到的各項性能指標值見表2和表3。測試過程中通過服務(wù)代理的方式監(jiān)控節(jié)點機器，實時抓取各節(jié)點的資源使用情況，并重點記錄了核心節(jié)點的資源使用率，具體見表4和表5，列表頭的1-cpu表示節(jié)點1的CPU資源使用特征。由于篇幅所限，只羅列比較關(guān)鍵的數(shù)據(jù)。

表2 普通集群架構(gòu)指標值

表3 本文集群架構(gòu)指標值

表4 普通集群下的節(jié)點表現(xiàn)/%

表5 本文集群下的節(jié)點表現(xiàn)/%

根據(jù)不同并發(fā)數(shù)測試得到的數(shù)據(jù)，轉(zhuǎn)換成兩種集群架構(gòu)的TPS和響應(yīng)時間變化曲線，分別如圖5、圖6所示，并且將相應(yīng)的節(jié)點表現(xiàn)轉(zhuǎn)換為曲線，如圖7、圖8所示。

圖5 TPS變化曲線

圖6 響應(yīng)時間變化曲線

圖7 Memory變化曲線

圖8 CPU變化曲線

此次測試中并未針對Tomcat容器、數(shù)據(jù)庫連接池等進行過多的配置參數(shù)優(yōu)化，相信后續(xù)加強對容器調(diào)優(yōu)，架構(gòu)的性能還有一定的上升空間。

4 結(jié)束語

本文從多角度挖掘高并發(fā)請求的痛點，從數(shù)據(jù)緩存、分布式鎖、消息隊列、負載均衡4個方面進行分析與研究，提出了一種適合高并發(fā)多線程競爭共享資源場景的高性能系統(tǒng)通用架構(gòu)。架構(gòu)基于Redis集群實現(xiàn)數(shù)據(jù)緩存，避免直擊數(shù)據(jù)庫；攔截失敗請求，提高系統(tǒng)吞吐量；采用分布式鎖，在系統(tǒng)垂直或水平擴展的情況下，保證同一時間的一個線程獲取到鎖，確保共享資源的安全性和一致性，同時采用基于cas算法的樂觀鎖方式避免Redis服務(wù)器與應(yīng)用服務(wù)器之間交互流量過高導(dǎo)致服務(wù)器壓力過大；借助消息隊列組件進行異步處理操作，降低數(shù)據(jù)庫服務(wù)陷入堵塞的風(fēng)險；從LVS調(diào)度轉(zhuǎn)發(fā)解決Nginx負載均衡的單點故障。本文架構(gòu)面臨流量沖擊仍可維持服務(wù)高可用，組件服務(wù)皆可縱向擴展，具有廣泛的通用性，可適用于高校搶課、高峰訂票、商品秒殺等典型場景，對于構(gòu)建高并發(fā)應(yīng)用具有一定參考價值。