偷偷摘套内射激情视频,久久精品99国产国产精,中文字幕无线乱码人妻,中文在线中文a,性爽19p

騰訊云分布式高可靠消息隊(duì)列CMQ架構(gòu)最佳實(shí)踐

企業(yè)動態(tài) 分布式
騰訊云基礎(chǔ)產(chǎn)品團(tuán)隊(duì):繼承騰訊內(nèi)部沉淀十多年的虛擬化、計(jì)算、網(wǎng)絡(luò)、存儲等基礎(chǔ)能力,深度開發(fā)KVM和SDN網(wǎng)絡(luò)虛擬化等底層技術(shù),開發(fā)高可用塊存儲和容器服務(wù),為業(yè)界打造一系列高可用高性能的彈性云產(chǎn)品,以及覆蓋互聯(lián)網(wǎng)和傳統(tǒng)行業(yè)的綜合解決方案。

閆二輝,騰訊云資深存儲架構(gòu)師,在大規(guī)模存儲、PaaS、虛擬化領(lǐng)域有長期深厚積累。目前主要從事互聯(lián)網(wǎng)中間件的設(shè)計(jì)研發(fā)相關(guān)工作。

騰訊云基礎(chǔ)產(chǎn)品團(tuán)隊(duì):繼承騰訊內(nèi)部沉淀十多年的虛擬化、計(jì)算、網(wǎng)絡(luò)、存儲等基礎(chǔ)能力,深度開發(fā)KVM和SDN網(wǎng)絡(luò)虛擬化等底層技術(shù),開發(fā)高可用塊存儲和容器服務(wù),為業(yè)界打造一系列高可用高性能的彈性云產(chǎn)品,以及覆蓋互聯(lián)網(wǎng)和傳統(tǒng)行業(yè)的綜合解決方案。

內(nèi)容目錄

1. 消息隊(duì)列的使用場景、價值

2. CMQ底層架構(gòu)剖析

3. CMQ對比開源rabbitMQ壓測

4. CMQ案例***實(shí)踐

01|消息隊(duì)列的使用場景

消息的收發(fā)解耦:發(fā)送方和接收方不需要了解彼此,甚至不需要知道對方的存在;

屏蔽不同平臺之間的差異:不同平臺之間通過消息來實(shí)現(xiàn)交互,僅僅關(guān)心消息的發(fā)送和讀?。?/p>

削峰填谷,提高系統(tǒng)應(yīng)對突發(fā)能力:發(fā)送消息端永遠(yuǎn)不會堵塞,突發(fā)消息緩存在CMQ SERVER 端,消費(fèi)者按照實(shí)際能力讀取消息;

一次生產(chǎn)多次消費(fèi):一條消息可以被多鐘類型消費(fèi)者訂閱,生產(chǎn)著僅需生產(chǎn)一次即可;

跨IDC/WAN傳輸:CMQ支持消息在不同IDC、城市進(jìn)行生產(chǎn)、消費(fèi),自動就近接入,對業(yè)務(wù)透明;

02|CMQ底層架構(gòu)剖析

 

在分布式大行其道的今天,我們在系統(tǒng)內(nèi)部、平臺之間廣泛運(yùn)用消息中間件進(jìn)行數(shù)據(jù)交換及解耦。CMQ是騰訊云內(nèi)部自研基于的高可靠、強(qiáng)一致、可擴(kuò)展分布式消息隊(duì)列,在騰訊內(nèi)部包括微信手機(jī)QQ業(yè)務(wù)紅包、騰訊話費(fèi)充值、廣告訂單等都有廣泛使用。目前已上線騰訊云對外開放,本文對CMQ 核心技術(shù)原理進(jìn)行分享介紹。

 

按照使用場景可以將消息中間件粗略分為:高可靠和高性能兩大類。CMQ主要適用于金融、交易、訂單等對可靠性、可用性有較高要求的業(yè)務(wù)場景。

 

如圖1以騰訊充值系統(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)模塊的壓力。

圖1-某充值系統(tǒng)結(jié)構(gòu)

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所示。

圖2-CMQ整體架構(gòu)圖

圖3-broker set 內(nèi)部結(jié)構(gòu)圖

下面分別中數(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ù)邏輯來保證。

存儲可靠

CMQSET中一個節(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所示。

圖4-數(shù)據(jù)存儲原理示意圖

由此可見,對于返回客戶端成功的消息至少是分別在兩個節(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ù)視圖。

圖5-1 網(wǎng)絡(luò)分區(qū)前     圖5-2 發(fā)生網(wǎng)絡(luò)分區(qū)     圖5-3 新leader對外服務(wù)          

可用性保證

圖6 leader 選舉流程

如上文所述,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所示,具體選舉算法請參考raft 論文。 

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ò)展,***堆積

圖7橫向擴(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)一致的分布式消息隊(duì)列,主要服務(wù)于訂單、交易類業(yè)務(wù)場景。消息的冪等性需業(yè)務(wù)側(cè)來保證,在特定情況下可以保證消息嚴(yán)格有序。

對于更側(cè)重高性能、高吞吐量業(yè)務(wù)需求,騰訊云由另外一個消息引擎來提供服務(wù),在協(xié)議上同時兼容kafka,很好的滿足了大數(shù)據(jù)場景,具體原理請留意后續(xù)文章介紹。

03|CMQ對比開源rabbitMQ壓測

RabbitMQ 是具有代表性的開源消息中間件,當(dāng)前較多地應(yīng)用于企業(yè)系統(tǒng)內(nèi),用于對數(shù)據(jù)一致性、穩(wěn)定性和可靠性要求較高的場景中。

CMQ也是強(qiáng)調(diào)高可靠的消息傳遞,那騰訊云的CMQ,對比rabbitMQ有哪些優(yōu)勢?

•  功能升級

除了生產(chǎn)、消費(fèi)確認(rèn)機(jī)制,CMQ還提供了消費(fèi)回溯功能。

用戶指定CMQ保存生產(chǎn)消息一定天數(shù),隨后將消費(fèi)回溯到該時間段內(nèi)某一時間點(diǎn),從該點(diǎn)開始重新消費(fèi)。在用戶業(yè)務(wù)邏輯異常時,以時間為起點(diǎn)的消息重放功能對業(yè)務(wù)恢復(fù)非常有幫助。

•  性能優(yōu)化

網(wǎng)絡(luò)IO:CMQ能夠批量生產(chǎn)/消費(fèi)消息,RabbitMQ則不支持批量生產(chǎn)。在大量小消息場景中,CMQ具有更少的請求數(shù)和更低的平均延遲。

文件IO:CMQ生產(chǎn)/消費(fèi)消息是順序?qū)憜蝹€文件,并周期落盤存儲,充分利用文件系統(tǒng)緩存。RabbitMQ持久化消息先入內(nèi)存隊(duì)列進(jìn)行狀態(tài)轉(zhuǎn)換,然后寫日志緩存,***寫消息文件和索引文件(索引文件為順序?qū)?、消息文件為隨機(jī)寫),涉及三次IO操作,性能較差。

CPU:RabbitMQ的日志緩存和狀態(tài)轉(zhuǎn)換運(yùn)算較復(fù)雜,大量耗用CPU。

•  可用性提升

CMQ和RabbitMQ都能夠使用多臺機(jī)器進(jìn)行熱備,提高可用性。CMQ基于Raft算法實(shí)現(xiàn),簡單易維護(hù)。RabbitMQ使用自創(chuàng)的GM算法(Guaranteed Multicast),學(xué)習(xí)難度高。

圖1  Raft日志復(fù)制

Raft協(xié)議中,Log復(fù)制只要大多數(shù)節(jié)點(diǎn)向Leader返回成功,Leader就可以應(yīng)用該請求,向客戶端返回成功。

圖2  GM環(huán)狀可靠多播

GM可靠多播將集群中所有節(jié)點(diǎn)組成一個環(huán)。Log復(fù)制依次從Leader向后繼節(jié)點(diǎn)傳播,當(dāng)Leader再次收到該請求時,發(fā)出確認(rèn)消息在環(huán)中傳播,直至Leader再次收到該確認(rèn)消息,表明Log在環(huán)中所有節(jié)點(diǎn)同步完成。

GM算法要求Log在集群所有節(jié)點(diǎn)同步之后才能向客戶端返回成功;Raft算法則只要求大多數(shù)節(jié)點(diǎn)同步完成。Raft算法在同步路徑上比GM算法減少了一半的等待時間。

壓測結(jié)果

經(jīng)內(nèi)部嚴(yán)格壓測,在同等網(wǎng)絡(luò)、CPU內(nèi)存環(huán)境下,CMQ在保證可靠傳遞的前提下,QPS表現(xiàn)是rabbitMQ的4倍以上。

 

04|CMQ15年微信春晚紅包案例

春晚紅包活動涉及四個大型系統(tǒng)的聯(lián)動,包括微信、微信支付、紅包系統(tǒng)和財付通系統(tǒng)。以下簡單介紹各個系統(tǒng):

紅包系統(tǒng):個人紅包的發(fā)、搶、拆和列表查看;

財付通系統(tǒng):包括支付訂單、異步入賬流水的高性能存儲,用戶余額和賬單的實(shí)時展示;

微信接入:確保微信用戶公網(wǎng)接入的質(zhì)量;

微信支付:在線交易的入口。

 

類似紅包系統(tǒng)的分布式事務(wù)是關(guān)注的熱點(diǎn)。舉一個典型的例子,“用戶A給用戶B發(fā)了10元的紅包”,有以下步驟:

 

1. 從A帳號中把余額讀出來

2. 對A帳號做減法操作(減10元)

3. 把結(jié)果寫回A帳號中(一次確認(rèn))

4. 從B帳號中把余額讀出來

5. 拆開A發(fā)送給B的紅包,讀出數(shù)值

6. 對B帳號做加法操作(加10元)

7. 把結(jié)果寫到B帳號中

 

為了保證數(shù)據(jù)的一致性,上述步驟只有兩種結(jié)果:都成功完成或者都不成功執(zhí)行回滾。而且這個操作的過程中,對A、B帳號還需引入分布式鎖機(jī)制來避免臟數(shù)據(jù)的問題。在微信紅包這個龐大的分布式集群內(nèi),事情將變的異常復(fù)雜。

 

微信紅包系統(tǒng)引入了騰訊云 CMQ 以避免分布式事務(wù)增加對系統(tǒng)的開銷。同樣A用戶給B用戶發(fā)10元紅包的場景,下面介紹引入CMQ 后的新策略。

 

在上述案例中的第七步,B 用戶拆開了紅包,紅包里有 10 塊錢。在做***的入賬操作時由于當(dāng)天并發(fā)壓力大,常出現(xiàn)入賬失敗的情況。

 

紅包團(tuán)隊(duì)把入帳失敗的請求,全部轉(zhuǎn)入CMQ。當(dāng)B用戶更新賬戶余額失敗時,手機(jī)客戶端顯示等待狀態(tài)。隨后入賬系統(tǒng)將不斷從 CMQ 重新拉取重試此更新操作。CMQ 保證了這 10 元的入賬消息永遠(yuǎn)不丟,直至它被取出。

 

在除夕當(dāng)天,用戶紅包的發(fā)、拆、入賬等動作,轉(zhuǎn)化為了十億級別的海量請求。若使用傳統(tǒng)的事務(wù)方式,會放大并發(fā)壓力使系統(tǒng)崩潰。

 

CMQ消息隊(duì)列保證了紅包消息的可靠存儲、傳遞,實(shí)時寫三份保證數(shù)據(jù)不丟。資金入賬失敗時,入賬系統(tǒng)可異步的多次重試,從CMQ拉數(shù)據(jù),直到成功,起削峰填谷的作用。避免失敗回滾和頻繁輪詢數(shù)據(jù)庫等傳統(tǒng)方式的弊端。

 

Q&A

 

Q1:創(chuàng)業(yè)公司怎么選擇消息隊(duì)列?

A1:開源的消息隊(duì)列有很多,實(shí)現(xiàn)機(jī)制復(fù)雜,運(yùn)維成本也很高,對于創(chuàng)業(yè)企業(yè)來說,選擇云服務(wù)商提供的消息隊(duì)列無疑是最省事的,按需使用,成本非常低。

 

Q2:CMQ生產(chǎn)的消息,如果未被消費(fèi)保存多久?

A2:消息在隊(duì)列中最長的存活時間,從發(fā)送到該隊(duì)列開始經(jīng)過此參數(shù)指定的時間后,不論消息是否被取出過都將被刪除;單位為秒,有效值范圍60-1296000秒,也即1分鐘到15天。

 

Q3:相比kafka有什么優(yōu)勢?

A3:跟kafka相比,各有側(cè)重點(diǎn),kafka更強(qiáng)調(diào)吞吐性能。CMQ強(qiáng)調(diào)是可靠傳遞,不丟。 CMQ的Kafka版本也即將推出,敬請期待。

 

Q4:CMQ消費(fèi)方式是push還是pull?還是兩者結(jié)合?

A4:當(dāng)前queue的模式我們采取的是pull的方式。后續(xù)的topic的模式會有push,可以支持push到http端,短信,郵件,和queue。

 

Q5:哪些隊(duì)列支持pubsub?

A5: 其實(shí)CMQ支持兩種產(chǎn)品形態(tài):queue和topic, 對于queue來說沒有pubsub功能,topic有pubsub的能力也能把topic和queue串聯(lián)起來使用,queue可以作為topic其中的一個sub方。

 

責(zé)任編輯:潤月 來源: 51CTO
相關(guān)推薦

2021-06-16 08:33:02

分布式事務(wù)ACID

2023-07-25 09:52:00

本地事務(wù)宕機(jī)

2018-07-31 16:29:57

京東云

2023-03-09 10:22:00

SpringBootRabbitMQ

2024-09-12 14:50:08

2024-11-14 11:56:45

2022-06-28 08:37:07

分布式服務(wù)器WebSocket

2021-10-30 19:30:23

分布式Celery隊(duì)列

2022-12-13 09:19:26

分布式消息隊(duì)列

2017-08-16 16:30:01

CMQ消息實(shí)踐

2023-07-26 07:28:55

WebSocket服務(wù)器方案

2019-09-12 08:50:37

Kafka分布式系統(tǒng)服務(wù)器

2021-05-06 10:12:14

鴻蒙HarmonyOS應(yīng)用

2021-03-10 08:56:37

Zookeeper

2021-02-26 08:32:28

RocketMQ阿里云

2016-08-24 15:43:01

2014-06-11 09:17:39

負(fù)載均衡

2014-05-23 10:30:25

負(fù)載均衡分布式架構(gòu)

2015-11-02 16:38:09

C#分布式消息隊(duì)列

2023-05-29 14:07:00

Zuul網(wǎng)關(guān)系統(tǒng)
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號