針對金融、交易、訂單等對可靠性、可用性有較高要求的業(yè)務(wù)場景，本文分享如何通過CMQ消息隊列實(shí)現(xiàn)高可用架構(gòu)
作者：張浩
出處：騰云閣文章
--------------------------------------------------------
在分布式大行其道的今天，我們在系統(tǒng)內(nèi)部、平臺之間廣泛運(yùn)用消息中間件進(jìn)行數(shù)據(jù)交換及解耦。CMQ是騰訊云內(nèi)部自研基于的高可靠、強(qiáng)一致、可擴(kuò)展分布式消息隊列，在騰訊內(nèi)部包括微信手機(jī)QQ業(yè)務(wù)紅包、騰訊話費(fèi)充值、廣告訂單等都有廣泛使用。目前已上線騰訊云對外開放，本文對騰訊云CMQ核心技術(shù)原理進(jìn)行分享介紹。
CMQ消息隊列主要適用于金融、交易、訂單等對可靠性、可用性有較高要求的業(yè)務(wù)場景。
以騰訊充值系統(tǒng)為例，該充值系統(tǒng)通過CMQ 對交易模塊、發(fā)貨部分、結(jié)算系統(tǒng)進(jìn)行異步解耦、削峰填谷，一方面大大降低了模塊間耦合度，另一方面減輕了大量突發(fā)請求對后端系統(tǒng)的沖擊。在月初充值該系統(tǒng)一天經(jīng)過CMQ轉(zhuǎn)發(fā)的消息超過十億條，每秒峰值超過10w，最高時有數(shù)億條消息通過CMQ的堆積能力緩沖了對后端消費(fèi)模塊的壓力。架構(gòu)如圖1：
圖中騰訊云消息隊列CMQ整體結(jié)構(gòu)如圖2所示，本文重點(diǎn)介紹后端broker set實(shí)現(xiàn)原理。通常情況下一個set由3個節(jié)點(diǎn)組成，通過多副本保證消息的可靠性、多節(jié)點(diǎn)提高系統(tǒng)可用性。當(dāng)然，可以根據(jù)業(yè)務(wù)的實(shí)際需求通過增加set內(nèi)節(jié)點(diǎn)個數(shù)來進(jìn)一步提高可靠性和可用性，
CMQ set 模塊內(nèi)部結(jié)構(gòu)如圖3所示。
下面分別中數(shù)據(jù)高可靠、強(qiáng)一致，系統(tǒng)可用性，可擴(kuò)展、消息全路徑追蹤方面分別介紹。
在可靠性保證方面主要包括以下三方面：生產(chǎn)可靠、存儲（堆積）可靠、消費(fèi)可靠：
生產(chǎn)可靠
如圖3所示，客戶端生產(chǎn)的消息在set 中超過半數(shù)的broker 刷盤成功后會返回確認(rèn)消息告知生產(chǎn)消息成功。如果在一定時間之內(nèi)客戶端沒有收到確認(rèn)信息需要重試來確保消息發(fā)送成功。
可靠生產(chǎn)帶來的一個問題就是消息的重復(fù)，在網(wǎng)絡(luò)異常等情況下很可能CMQ broker已經(jīng)存儲消息成功只是確認(rèn)包在網(wǎng)絡(luò)上丟失了，這樣客戶端重試生產(chǎn)后，在broker上存在兩條重復(fù)的消息。考慮到消息去重開銷較大，目前消息的冪等性需要業(yè)務(wù)邏輯來保證。
存儲可靠
CMQ SET中一個節(jié)點(diǎn)為leader 其他節(jié)點(diǎn)為follower，leader 負(fù)責(zé)所有消息的生產(chǎn)消費(fèi)。當(dāng)生產(chǎn)消息到達(dá)leader 節(jié)點(diǎn)后，通過raft 一致性模塊將請求順序?qū)憆aft log 并同步刷盤，同時將構(gòu)造好的raft log 按順序通過網(wǎng)絡(luò)發(fā)送到其他follower節(jié)點(diǎn)，follower節(jié)點(diǎn)同步刷盤并返回成功。當(dāng)leader 收到過半數(shù)的節(jié)點(diǎn)同步成功信息后將此條請求提交到mq 處理狀態(tài)機(jī)，由mq 狀態(tài)機(jī)將請求應(yīng)用到相應(yīng)queue。大致邏輯圖4所示。
由此可見，對于返回客戶端成功的消息至少是分別在兩個節(jié)點(diǎn)磁盤上存儲成功的，這就將磁盤故障引起的數(shù)據(jù)丟失大大降低。另外數(shù)據(jù)在磁盤上存儲時會將檢驗(yàn)結(jié)果一同記下來，消費(fèi)者在消費(fèi)數(shù)據(jù)之前CMQ broker 會進(jìn)行比較，確保消息是完整有效的。
消費(fèi)可靠
消費(fèi)者拉取消息時會指定當(dāng)前消息的隱藏時間，在隱藏時間內(nèi)消費(fèi)者比較顯式的對消息進(jìn)行確認(rèn)刪除，如果超過隱藏時間沒有主動刪除，此條消息將重新對外可見，可以繼續(xù)消費(fèi)。
顯式確認(rèn)刪除消息是為了防止消息在投遞、處理過程中異常而導(dǎo)致的消息丟失。
對于消息的確認(rèn)信息 CMQ broker的處理邏輯和生產(chǎn)消息過程類似，也是一個寫入的過程，不同的是此時寫入的數(shù)據(jù)的內(nèi)容是msgid 和消息狀態(tài)。
強(qiáng)一致實(shí)現(xiàn)
假如一個set中有3個節(jié)點(diǎn)(A, B, C),A為leader，B C 是follower。如上圖所示，對于返回客戶端成功的請求數(shù)據(jù)在CMQ 中至少在兩個節(jié)點(diǎn)上存在,假設(shè)為A B，此時如果leader A故障，B C 兩個follower 會自動選舉出一個新leader，CMQ 使用的raft 算法可以保證這個leader 一定是擁有最全量log 信息中的一個，在此必定是B。此時B繼續(xù)對外服務(wù)，B 和A 擁有相同的已經(jīng)返回確認(rèn)給用戶的全量數(shù)據(jù)視圖，數(shù)據(jù)是強(qiáng)一致的。
對于A 和 B C 所在的網(wǎng)絡(luò)發(fā)生分區(qū)的情況（如圖5），由于leader A得不到set 中過半節(jié)點(diǎn)的回復(fù)所以不能處理請求，B C在選舉超時后會選舉出一個新的leader ，CMQ的接入層會自動進(jìn)行切換。Raft 算法保證新leader 同樣具有完成的數(shù)據(jù)視圖。
可用性保證
如上文所述，master 負(fù)責(zé)所有消息的生產(chǎn)消費(fèi)，當(dāng)master 故障時SET中其他follower節(jié)點(diǎn)會自動選舉出一個新leader，客戶端請求會自動重定向到leader節(jié)點(diǎn)，RTO和配置的選舉超時時間有關(guān)，目前是在5s左右。大致過程如上圖6所示。
CMQ單個set 在CAP理論中優(yōu)先保證了CP，當(dāng)SET中過半數(shù)節(jié)點(diǎn)都正常工作時，才能進(jìn)行消息的生產(chǎn)消費(fèi)。對于SET多個節(jié)點(diǎn)同時故障的不可用情況，CMQ強(qiáng)大的監(jiān)控調(diào)度能力能夠快速對queue進(jìn)行調(diào)度遷移恢復(fù)服務(wù)，將不可用時間降到最低。
橫向擴(kuò)展，無限堆積
上文中SET的概念對用戶來說是透明無感知的，CMQ controller server 根據(jù)set的負(fù)載情況實(shí)時對queue進(jìn)行調(diào)度搬遷。如果某個queue的請求量超過當(dāng)前set的服務(wù)閾值，controller server 可以將queue 路由分布到多個set 上來提高并發(fā)量，對于需要海量堆積的服務(wù)來說可以通過路由調(diào)度來提升堆積上限，理論上可以達(dá)到無限堆積。
目前CMQ只能保證特定情況下消息的嚴(yán)格有序，例如需要保證單個生產(chǎn)進(jìn)程、單個消費(fèi)進(jìn)程，或者queue的消費(fèi)窗口設(shè)定為1等條件。
全路徑消息trace
CMQ系統(tǒng)中，一條消息的完整路徑包含生產(chǎn)者、broker、消費(fèi)者三個角色，每個角色處理消息的過程中都會在trace 路徑中增加相關(guān)的信息，將這些信息匯聚即可獲取任意一條消息的狀態(tài)和當(dāng)前經(jīng)過的完整路徑，從而為生產(chǎn)環(huán)境中的問題排查提供強(qiáng)有力的數(shù)據(jù)支持。大大降低了業(yè)務(wù)定位問題的難度。
小結(jié)
CMQ是基于raft 算法來保證數(shù)據(jù)高可靠、強(qiáng)一致的分布式消息隊列，主要服務(wù)于訂單、交易類業(yè)務(wù)場景。消息的冪等性需業(yè)務(wù)側(cè)來保證，在特定情況下可以保證消息嚴(yán)格有序。
對于更側(cè)重高性能、高吞吐量業(yè)務(wù)需求，騰訊云由另外一個消息引擎來提供服務(wù)，在協(xié)議上同時兼容kafka，很好的滿足了大數(shù)據(jù)場景，具體原理請留意后續(xù)文章介紹。
------------------------------------------
獲取更多云計算技術(shù)干貨，可請前往?騰訊云技術(shù)社區(qū)
我也會持續(xù)同步更新~
微信公眾號：騰訊云技術(shù)社區(qū)（ QcloudCommunity）
