簡(jiǎn)介：2020 年雙十一交易峰值達(dá)到 58.3 W 筆/秒，消息中間件 RocketMQ 繼續(xù)數(shù)年 0 故障絲般順滑地完美支持了整個(gè)集團(tuán)大促的各類業(yè)務(wù)平穩(wěn)。

作者 | 愈安
來源 | 阿里巴巴云原生公眾號(hào)

2020 年雙十一交易峰值達(dá)到 58.3 W 筆/秒，消息中間件 RocketMQ 繼續(xù)數(shù)年 0 故障絲般順滑地完美支持了整個(gè)集團(tuán)大促的各類業(yè)務(wù)平穩(wěn)。2020 年雙十一大促中，消息中間件 RocketMQ 發(fā)生了以下幾個(gè)方面的變化：

• 云原生化實(shí)踐：完成運(yùn)維層面的云原生化改造，實(shí)現(xiàn) Kubernetes 化。
• 性能優(yōu)化：消息過濾優(yōu)化交易集群性能提升 30%。
• 全新的消費(fèi)模型：對(duì)于延遲敏感業(yè)務(wù)提供新的消費(fèi)模式，降低因發(fā)布、重啟等場(chǎng)景下導(dǎo)致的消費(fèi)延遲。

云原生化實(shí)踐

1. 背景

Kubernetes 作為目前云原生化技術(shù)棧實(shí)踐中重要的一環(huán)，其生態(tài)已經(jīng)逐步建立并日益豐富。目前，服務(wù)于集團(tuán)內(nèi)部的 RocketMQ 集群擁有巨大的規(guī)模以及各種歷史因素，因此在運(yùn)維方面存在相當(dāng)一部分痛點(diǎn)，我們希望能夠通過云原生技術(shù)棧來嘗試找到對(duì)應(yīng)解決方案，并同時(shí)實(shí)現(xiàn)降本提效，達(dá)到無人值守的自動(dòng)化運(yùn)維。

消息中間件早在 2016 年，通過內(nèi)部團(tuán)隊(duì)提供的中間件部署平臺(tái)實(shí)現(xiàn)了容器化和自動(dòng)化發(fā)布，整體的運(yùn)維比 2016 年前已經(jīng)有了很大的提高，但是作為一個(gè)有狀態(tài)的服務(wù)，在運(yùn)維層面仍然存在較多的問題。

中間件部署平臺(tái)幫我們完成了資源的申請(qǐng)，容器的創(chuàng)建、初始化、鏡像安裝等一系列的基礎(chǔ)工作，但是因?yàn)橹虚g件各個(gè)產(chǎn)品都有自己不同的部署邏輯，所以在應(yīng)用的發(fā)布上，就是各應(yīng)用自己的定制化了。中間件部署平臺(tái)的開發(fā)也不完全了解集團(tuán)內(nèi) RocketMQ 的部署過程是怎樣的。

因此在 2016 年的時(shí)候，部署平臺(tái)需要我們?nèi)ビH自實(shí)現(xiàn)消息中間件的應(yīng)用發(fā)布代碼。雖然部署平臺(tái)大大提升了我們的運(yùn)維效率，甚至還能實(shí)現(xiàn)一鍵發(fā)布，但是這樣的方案也有不少的問題。比較明顯的就是，當(dāng)我們的發(fā)布邏輯有變化的時(shí)候，還需要去修改部署平臺(tái)對(duì)應(yīng)的代碼，需要部署平臺(tái)升級(jí)來支持我們，用最近比較流行的一個(gè)說法，就是相當(dāng)不云原生。

同樣在故障機(jī)替換、集群縮容等操作中，存在部分人工參與的工作，如切流，堆積數(shù)據(jù)的確認(rèn)等。我們嘗試過在部署平臺(tái)中集成更多消息中間件自己的運(yùn)維邏輯，不過在其他團(tuán)隊(duì)的工程里寫自己的業(yè)務(wù)代碼，確實(shí)也是一個(gè)不太友好的實(shí)現(xiàn)方案，因此我們希望通過 Kubernetes 來實(shí)現(xiàn)消息中間件自己的 operator 。我們同樣希望利用云化后云盤的多副本能力來降低我們的機(jī)器成本并降低主備運(yùn)維的復(fù)雜程度。

經(jīng)過一段時(shí)間的跟進(jìn)與探討，最終再次由內(nèi)部團(tuán)隊(duì)承擔(dān)了建設(shè)云原生應(yīng)用運(yùn)維平臺(tái)的任務(wù)，并依托于中間件部署平臺(tái)的經(jīng)驗(yàn)，借助云原生技術(shù)棧，實(shí)現(xiàn)對(duì)有狀態(tài)應(yīng)用自動(dòng)化運(yùn)維的突破。

2. 實(shí)現(xiàn)

整體的實(shí)現(xiàn)方案如上圖所示，通過自定義的 CRD 對(duì)消息中間件的業(yè)務(wù)模型進(jìn)行抽象，將原有的在中間件部署平臺(tái)的業(yè)務(wù)發(fā)布部署邏輯下沉到消息中間件自己的 operator 中，托管在內(nèi)部 Kubernetes 平臺(tái)上。該平臺(tái)負(fù)責(zé)所有的容器生產(chǎn)、初始化以及集團(tuán)內(nèi)一切線上環(huán)境的基線部署，屏蔽掉 IaaS 層的所有細(xì)節(jié)。

Operator 承擔(dān)了所有的新建集群、擴(kuò)容、縮容、遷移的全部邏輯，包括每個(gè) pod 對(duì)應(yīng)的 brokerName 自動(dòng)生成、配置文件，根據(jù)集群不同功能而配置的各種開關(guān)，元數(shù)據(jù)的同步復(fù)制等等。同時(shí)之前一些人工的相關(guān)操作，比如切流時(shí)候的流量觀察，下線前的堆積數(shù)據(jù)觀察等也全部集成到了 operator 中。當(dāng)我們有需求重新修改各種運(yùn)維邏輯的時(shí)候，也再也不用去依賴通用的具體實(shí)現(xiàn)，修改自己的 operator 即可。

最后線上的實(shí)際部署情況去掉了圖中的所有的 replica 備機(jī)。在 Kubernetes 的理念中，一個(gè)集群中每個(gè)實(shí)例的狀態(tài)是一致的，沒有依賴關(guān)系，而如果按照消息中間件原有的主備成對(duì)部署的方案，主備之間是有嚴(yán)格的對(duì)應(yīng)關(guān)系，并且在上下線發(fā)布過程中有嚴(yán)格的順序要求，這種部署模式在 Kubernetes 的體系下是并不提倡的。若依然采用以上老的架構(gòu)方式，會(huì)導(dǎo)致實(shí)例控制的復(fù)雜性和不可控性，同時(shí)我們也希望能更多的遵循 Kubernetes 的運(yùn)維理念。

云化后的 ECS 使用的是高速云盤，底層將對(duì)數(shù)據(jù)做了多備份，因此數(shù)據(jù)的可用性得到了保障。并且高速云盤在性能上完全滿足 MQ 同步刷盤，因此，此時(shí)就可以把之前的異步刷盤改為同步，保證消息寫入時(shí)的不丟失問題。云原生模式下，所有的實(shí)例環(huán)境均是一致性的，依托容器技術(shù)和 Kubernetes 的技術(shù)，可實(shí)現(xiàn)任何實(shí)例掛掉（包含宕機(jī)引起的掛掉），都能自動(dòng)自愈，快速恢復(fù)。

解決了數(shù)據(jù)的可靠性和服務(wù)的可用性后，整個(gè)云原生化后的架構(gòu)可以變得更加簡(jiǎn)單，只有 broker 的概念，再無主備之分。

3. 大促驗(yàn)證

上圖是 Kubernetes 上線后雙十一大促當(dāng)天的發(fā)送 RT 統(tǒng)計(jì)，可見大促期間的發(fā)送 RT 較為平穩(wěn)，整體符合預(yù)期，云原生化實(shí)踐完成了關(guān)鍵性的里程碑。

性能優(yōu)化

1. 背景

RocketMQ 至今已經(jīng)連續(xù)七年 0 故障支持集團(tuán)的雙十一大促。自從 RocketMQ 誕生以來，為了能夠完全承載包括集團(tuán)業(yè)務(wù)中臺(tái)交易消息等核心鏈路在內(nèi)的各類關(guān)鍵業(yè)務(wù)，復(fù)用了原有的上層協(xié)議邏輯，使得各類業(yè)務(wù)方完全無感知的切換到 RocketMQ 上，并同時(shí)充分享受了更為穩(wěn)定和強(qiáng)大的 RocketMQ 消息中間件的各類特性。

當(dāng)前，申請(qǐng)訂閱業(yè)務(wù)中臺(tái)的核心交易消息的業(yè)務(wù)方一直都在不斷持續(xù)增加，并且隨著各類業(yè)務(wù)復(fù)雜度提升，業(yè)務(wù)方的消息訂閱配置也變得更加復(fù)雜繁瑣，從而使得交易集群的進(jìn)行過濾的計(jì)算邏輯也變得更為復(fù)雜。這些業(yè)務(wù)方部分沿用舊的協(xié)議邏輯（Header 過濾），部分使用 RocketMQ 特有的 SQL 過濾。

2. 主要成本

目前集團(tuán)內(nèi)部 RocketMQ 的大促機(jī)器成本絕大部分都是交易消息相關(guān)的集群，在雙十一零點(diǎn)峰值期間，交易集群的峰值和交易峰值成正比，疊加每年新增的復(fù)雜訂閱帶來了額外 CPU 過濾計(jì)算邏輯，交易集群都是大促中機(jī)器成本增長最大的地方。

3. 優(yōu)化過程

由于歷史原因，大部分的業(yè)務(wù)方主要還是使用 Header 過濾，內(nèi)部實(shí)現(xiàn)其實(shí)是aviator 表達(dá)式。仔細(xì)觀察交易消息集群的業(yè)務(wù)方過濾表達(dá)式，可以發(fā)現(xiàn)絕大部分都指定類似MessageType == xxxx這樣的條件。翻看 aviator 的源碼可以發(fā)現(xiàn)這樣的條件最終會(huì)調(diào)用 Java 的字符串比較String.compareTo()。

由于交易消息包括大量不同業(yè)務(wù)的 MessageType，光是有記錄的起碼有幾千個(gè)，隨著交易業(yè)務(wù)流程復(fù)雜化，MessageType 的增長更是繁多。隨著交易峰值的提高，交易消息峰值正比增長，疊加這部分更加復(fù)雜的過濾，持續(xù)增長的將來，交易集群的成本極可能和交易峰值指數(shù)增長，因此決心對(duì)這部分進(jìn)行優(yōu)化。

原有的過濾流程如下，每個(gè)交易消息需要逐個(gè)匹配不同 group 的訂閱關(guān)系表達(dá)式，如果符合表達(dá)式，則選取對(duì)應(yīng)的 group 的機(jī)器進(jìn)行投遞。如下圖所示：

對(duì)此流程進(jìn)行優(yōu)化的思路需要一定的靈感，在這里借助數(shù)據(jù)庫索引的思路：原有流程可以把所有訂閱方的過濾表達(dá)式看作數(shù)據(jù)庫的記錄，每次消息過濾就相當(dāng)于一個(gè)帶有特定條件的數(shù)據(jù)庫查詢，把所有匹配查詢（消息）的記錄（過濾表達(dá)式）選取出來作為結(jié)果。為了加快查詢結(jié)果，可以選擇 MessageType 作為一個(gè)索引字段進(jìn)行索引化，每次查詢變?yōu)橄绕ヅ?MessageType 主索引，然后把匹配上主索引的記錄再進(jìn)行其它條件(如下圖的 sellerId 和 testA )匹配，優(yōu)化流程如下圖所示：

以上優(yōu)化流程確定后，要關(guān)注的技術(shù)點(diǎn)有兩個(gè)：

• 如何抽取每個(gè)表達(dá)式中的 MessageType 字段？
• 如何對(duì) MessageType 字段進(jìn)行索引化？

對(duì)于技術(shù)點(diǎn) 1 ，需要針對(duì) aviator 的編譯流程進(jìn)行 hook ，深入 aviator 源碼后，可以發(fā)現(xiàn) aviator 的編譯是典型的Recursive descent，同時(shí)需要考慮到提取后父表達(dá)式的短路問題。

在編譯過程中針對(duì) messageType==XXX 這種類型進(jìn)行提取后，把原有的 message==XXX 轉(zhuǎn)變?yōu)?true/false 兩種情況，然后針對(duì) true、false 進(jìn)行表達(dá)式的短路即可得出表達(dá)式優(yōu)化提取后的情況。例如：

表達(dá)式： messageType=='200-trade-paid-done' && buyerId==123456 提取為兩個(gè)子表達(dá)式： 子表達(dá)式1（messageType==200-trade-paid-done）：buyerId==123456 子表達(dá)式2（messageType!=200-trade-paid-done）：false

• 具體到 aviator 的實(shí)現(xiàn)里，表達(dá)式編譯會(huì)把每個(gè) token 構(gòu)建一個(gè) List ，類似如下圖所示(為方便理解，綠色方框的是 token ，其它框表示表達(dá)式的具體條件組合)：

提取了 messageType ，有兩種情況：

• 情況一：messageType == '200-trade-paid-done'，則把之前 token 的位置合并成true，然后進(jìn)行表達(dá)式短路計(jì)算，最后優(yōu)化成 buyerId==123456 ，具體如下：

• 情況二：messageType != '200-trade-paid-done'，則把之前 token 的位置合并成 false ，表達(dá)式短路計(jì)算后，最后優(yōu)化成 false ，具體如下：

這樣就完成 messageType 的提取。這里可能有人就有一個(gè)疑問，為什么要考慮到上面的情況二，messageType != '200-trade-paid-done'，這是因?yàn)楸仨氁紤]到多個(gè)條件的時(shí)候，比如：

(messageType=='200-trade-paid-done' && buyerId==123456) || (messageType=='200-trade-success' && buyerId==3333)

就必須考慮到不等于的情況了。同理，如果考慮到多個(gè)表達(dá)式嵌套，需要逐步進(jìn)行短路計(jì)算。但整體邏輯是類似的，這里就不再贅述。

說完技術(shù)點(diǎn) 1，我們繼續(xù)關(guān)注技術(shù)點(diǎn) 2，考慮到高效過濾，直接使用 HashMap 結(jié)構(gòu)進(jìn)行索引化即可，即把 messageType 的值作為 HashMap 的 key ，把提取后的子表達(dá)式作為 HashMap 的 value ，這樣每次過濾直接通過一次 hash 計(jì)算即可過濾掉絕大部分不適合的表達(dá)式，大大提高了過濾效率。

3. 優(yōu)化效果

該優(yōu)化最主要降低了 CPU 計(jì)算邏輯，根據(jù)優(yōu)化前后的性能情況對(duì)比，我們發(fā)現(xiàn)不同的交易集群中的訂閱方訂閱表達(dá)式復(fù)雜度越高，優(yōu)化效果越好，這個(gè)是符合我們的預(yù)期的，其中最大的 CPU 優(yōu)化有32%的提升，大大降低了本年度 RocketMQ 的部署機(jī)器成本。

全新的消費(fèi)模型 —— POP 消費(fèi)

1. 背景

RocketMQ 的 PULL 消費(fèi)對(duì)于機(jī)器異常 hang 時(shí)并不十分友好。如果遇到客戶端機(jī)器 hang 住，但處于半死不活的狀態(tài)，與 broker 的心跳沒有斷掉的時(shí)候，客戶端 rebalance 依然會(huì)分配消費(fèi)隊(duì)列到 hang 機(jī)器上，并且 hang 機(jī)器消費(fèi)速度很慢甚至無法消費(fèi)的時(shí)候，這樣會(huì)導(dǎo)致消費(fèi)堆積。另外類似還有服務(wù)端 Broker 發(fā)布時(shí)，也會(huì)由于客戶端多次 rebalance 導(dǎo)致消費(fèi)延遲影響等無法避免的問題。如下圖所示：

當(dāng) Pull Client 2 發(fā)生 hang 機(jī)器的時(shí)候，它所分配到的三個(gè) Broker 上的 Q2 都出現(xiàn)嚴(yán)重的紅色堆積。對(duì)于此，我們?cè)黾恿艘环N新的消費(fèi)模型 —— POP 消費(fèi)，能夠解決此類穩(wěn)定性問題。如下圖所示：

POP 消費(fèi)中，三個(gè)客戶端并不需要 rebalance 去分配消費(fèi)隊(duì)列，取而代之的是，它們都會(huì)使用 POP 請(qǐng)求所有的 broker 獲取消息進(jìn)行消費(fèi)。broker 內(nèi)部會(huì)把自身的三個(gè)隊(duì)列的消息根據(jù)一定的算法分配給請(qǐng)求的 POP Client。即使 Pop Client 2 出現(xiàn) hang，但內(nèi)部隊(duì)列的消息也會(huì)讓 Pop Client1 和 Pop Client2 進(jìn)行消費(fèi)。這樣就 hang 機(jī)器造成的避免了消費(fèi)堆積。

2. 實(shí)現(xiàn)

POP 消費(fèi)和原來 PULL 消費(fèi)對(duì)比，最大的一點(diǎn)就是弱化了隊(duì)列這個(gè)概念，PULL 消費(fèi)需要客戶端通過 rebalance 把 broker 的隊(duì)列分配好，從而去消費(fèi)分配到自己專屬的隊(duì)列，新的 POP 消費(fèi)中，客戶端的機(jī)器會(huì)直接到每個(gè) broker 的隊(duì)列進(jìn)行請(qǐng)求消費(fèi)， broker 會(huì)把消息分配返回給等待的機(jī)器。隨后客戶端消費(fèi)結(jié)束后返回對(duì)應(yīng)的 Ack 結(jié)果通知 broker，broker 再標(biāo)記消息消費(fèi)結(jié)果，如果超時(shí)沒響應(yīng)或者消費(fèi)失敗，再會(huì)進(jìn)行重試。

POP 消費(fèi)的架構(gòu)圖如上圖所示。Broker 對(duì)于每次 POP 的請(qǐng)求，都會(huì)有以下三個(gè)操作：

• 對(duì)應(yīng)的隊(duì)列進(jìn)行加鎖，然后從 store 層獲取該隊(duì)列的消息；
• 然后寫入 CK 消息，表明獲取的消息要被 POP 消費(fèi)；
• 最后提交當(dāng)前位點(diǎn)，并釋放鎖。

CK 消息實(shí)際上是記錄了 POP 消息具體位點(diǎn)的定時(shí)消息，當(dāng)客戶端超時(shí)沒響應(yīng)的時(shí)候，CK 消息就會(huì)重新被 broker 消費(fèi)，然后把 CK 消息的位點(diǎn)的消息寫入重試隊(duì)列。如果 broker 收到客戶端的消費(fèi)結(jié)果的 Ack ，刪除對(duì)應(yīng)的 CK 消息，然后根據(jù)具體結(jié)果判斷是否需要重試。

從整體流程可見，POP 消費(fèi)并不需要 reblance ，可以避免 rebalance 帶來的消費(fèi)延時(shí)，同時(shí)客戶端可以消費(fèi) broker 的所有隊(duì)列，這樣就可以避免機(jī)器 hang 而導(dǎo)致堆積的問題。

原文鏈接：https://developer.aliyun.com/article/783358?

版權(quán)聲明：本文內(nèi)容由阿里云實(shí)名注冊(cè)用戶自發(fā)貢獻(xiàn)，版權(quán)歸原作者所有，阿里云開發(fā)者社區(qū)不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。具體規(guī)則請(qǐng)查看《阿里云開發(fā)者社區(qū)用戶服務(wù)協(xié)議》和《阿里云開發(fā)者社區(qū)知識(shí)產(chǎn)權(quán)保護(hù)指引》。如果您發(fā)現(xiàn)本社區(qū)中有涉嫌抄襲的內(nèi)容，填寫侵權(quán)投訴表單進(jìn)行舉報(bào)，一經(jīng)查實(shí)，本社區(qū)將立刻刪除涉嫌侵權(quán)內(nèi)容。

總結(jié)

以上是生活随笔為你收集整理的阿里 RocketMQ 如何让双十一峰值之下 0 故障？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。