最近這不是趕上了金九銀十了啊造壮，然后公司也面試了幾個(gè)，有幸骂束，我跟著老大也經(jīng)歷了幾個(gè)面試場(chǎng)景费薄，其中一個(gè)讓我真的是印象深刻

他說(shuō)他在原公司是資深工程師級(jí)別，就相當(dāng)于技術(shù)骨干栖雾，然后公司項(xiàng)目也不錯(cuò)楞抡，就在我和老大都覺(jué)得不錯(cuò)的時(shí)候，我多問(wèn)了一句析藕，你們的消息中間件是怎么選型的召廷，這大哥給我回了一句：boss決定用這個(gè)的

扭頭看著老大逐漸石化的面龐，我就又問(wèn)了一下他們用的中間件RocketMQ相關(guān)內(nèi)容。竞慢。先紫。。剩下的我就不說(shuō)了（大哥筹煮，你面試的時(shí)候長(zhǎng)點(diǎn)心罢诰），幸好我們公司有個(gè)項(xiàng)目用到的技術(shù)跟架構(gòu)他回答的不錯(cuò)败潦，不然本冲，哎。劫扒。檬洞。

下面，技術(shù)上沟饥，我們來(lái)看一下添怔，他們當(dāng)時(shí)為什么會(huì)選用RocketMQ的，其實(shí)這個(gè)技術(shù)真的還不錯(cuò)

RocketMQ 介紹

Apache RocketMQ 是一款 低延遲贤旷、高并發(fā)广料、高可用寞冯、高可靠的分布式消息中間件嗅骄。消息隊(duì)列 RocketMQ 可為分布式應(yīng)用系統(tǒng)提供異步解耦和削峰填谷的能力，同時(shí)也具備互聯(lián)網(wǎng)應(yīng)用所需的海量消息堆積屠尊、高吞吐县遣、可靠重試等特性糜颠。

RocketMQ 概念

Topic：消息主題，用于將一類的消息進(jìn)行歸類萧求，比如訂單主題其兴，就是所有訂單相關(guān)的消息都可以由這個(gè)主題去承載，生產(chǎn)者向這個(gè)主題發(fā)送消息夸政。

生產(chǎn)者：負(fù)責(zé)生產(chǎn)消息并發(fā)送消息到 Topic 的角色元旬。

消費(fèi)者：負(fù)責(zé)從 Topic 接收并消費(fèi)消息 的角色。

消息：生產(chǎn)者向 Topic 發(fā)送的內(nèi)容守问，會(huì)被消費(fèi)者消費(fèi)匀归。

消息屬性：生產(chǎn)者發(fā)送的時(shí)候可以為消息自定義一些業(yè)務(wù)相關(guān)的屬性，比如 Message Key 和 Tag 等耗帕。

Group：一類生產(chǎn)者或消費(fèi)者穆端，這類生產(chǎn)者或消費(fèi)者通常生產(chǎn)或消費(fèi)同一類消息，且消息發(fā)布或訂閱的邏輯一致仿便。

為什么要使用 RocketMQ体啰？

異步解耦

隨著微服務(wù)架構(gòu)的流行攒巍，服務(wù)之間的關(guān)系梳理非常重要。異步解耦可以降低服務(wù)之間的耦合程度荒勇，同時(shí)也能提高服務(wù)的吞吐量柒莉。

使用異步解耦的業(yè)務(wù)場(chǎng)景非常多，因?yàn)槊總€(gè)行業(yè)的業(yè)務(wù)都會(huì)不太一樣沽翔，以一些比較通用的業(yè)務(wù)來(lái)說(shuō)明相信大家都能理解兢孝。

比如電商行業(yè)的下單業(yè)務(wù)場(chǎng)景，以最簡(jiǎn)單的下單流程來(lái)說(shuō)仅偎，下單流程如下：

鎖庫(kù)存

創(chuàng)建訂單

用戶支付

扣減庫(kù)存

給用戶發(fā)送購(gòu)買短信通知

給用戶增加積分

通知商家發(fā)貨

我們以下單成功后跨蟹，用戶進(jìn)行支付，支付完成會(huì)有個(gè)邏輯叫支付回調(diào)哨颂，在回調(diào)里面需要去做一些業(yè)務(wù)邏輯喷市。首先來(lái)看下同步處理需要花費(fèi)的時(shí)間相种，如下圖：

?

上面的下單流程從 3 到 5 都是可以采用異步流程進(jìn)行處理威恼，對(duì)于用戶來(lái)說(shuō)，支付完成后他就不需要關(guān)注后面的流程了寝并。后臺(tái)慢慢處理就行了箫措，這樣就能簡(jiǎn)化三個(gè)步驟，提高回調(diào)的處理時(shí)間衬潦。

?

削峰填谷

削峰填谷指的是在大流量的沖擊下斤蔓，利用 RocketMQ 可以抗住瞬時(shí)的大流量，保護(hù)系統(tǒng)的穩(wěn)定性镀岛，提升用戶體驗(yàn)弦牡。

在電商行業(yè)，最常見(jiàn)的流量沖擊就是秒殺活動(dòng)了漂羊，利用 RocketMQ 來(lái)實(shí)現(xiàn)一個(gè)完整的秒殺業(yè)務(wù)還是與很多需要做的工作驾锰，不在本文的范圍內(nèi)，后面有機(jī)會(huì)可以單獨(dú)跟大家聊聊走越。想告訴大家的是像諸如此類的場(chǎng)景可以利用 RocketMQ 來(lái)扛住高并發(fā)椭豫，前提是業(yè)務(wù)場(chǎng)景支持異步處理。

?

分布式事務(wù)最終一致性

眾所周知旨指，分布式事務(wù)有 2PC赏酥，TCC，最終一致性等方案谆构。其中使用消息隊(duì)列來(lái)做最終一致性方案是比較常用的裸扶。

在電商的業(yè)務(wù)場(chǎng)景中，交易相關(guān)的核心業(yè)務(wù)一定要確保數(shù)據(jù)的一致性搬素。通過(guò)引入消息隊(duì)列 RocketMQ 版的分布式事務(wù)呵晨，既可以實(shí)現(xiàn)系統(tǒng)之間的解耦瞬项，又可以保證最終的數(shù)據(jù)一致性。

數(shù)據(jù)分發(fā)

數(shù)據(jù)分發(fā)指的是可以將原始數(shù)據(jù)分發(fā)到多個(gè)需要使用這份數(shù)據(jù)的系統(tǒng)中何荚，實(shí)現(xiàn)數(shù)據(jù)異構(gòu)的需求囱淋。最常見(jiàn)的有將數(shù)據(jù)分發(fā)到 ES, Redis 中為業(yè)務(wù)提供搜索，緩存等服務(wù)餐塘。

除了手動(dòng)通過(guò)消息機(jī)制進(jìn)行數(shù)據(jù)分發(fā)妥衣，還可以訂閱 Mysql 的 binlog 來(lái)分發(fā)，在分發(fā)這個(gè)場(chǎng)景戒傻，需要使用 RocketMQ 的順序消息來(lái)保證數(shù)據(jù)的一致性税手。

?

RocketMQ 架構(gòu)

?

圖片來(lái)源阿里云官方文檔

Name Server：是一個(gè)幾乎無(wú)狀態(tài)節(jié)點(diǎn)，可集群部署需纳，在消息隊(duì)列 RocketMQ 版中提供命名服務(wù)芦倒，更新和發(fā)現(xiàn) Broker 服務(wù)。就是一個(gè)注冊(cè)中心不翩。

Broker：消息中轉(zhuǎn)角色兵扬，負(fù)責(zé)存儲(chǔ)消息，轉(zhuǎn)發(fā)消息口蝠。分為 Master Broker 和 Slave Broker器钟，一個(gè) Master Broker 可以對(duì)應(yīng)多個(gè) Slave Broker，但是一個(gè) Slave Broker 只能對(duì)應(yīng)一個(gè) Master Broker妙蔗。Broker 啟動(dòng)后需要完成一次將自己注冊(cè)至 Name Server 的操作傲霸；隨后每隔 30s 定期向 Name Server 上報(bào) Topic 路由信息。

生產(chǎn)者：與 Name Server 集群中的其中一個(gè)節(jié)點(diǎn)（隨機(jī)）建立長(zhǎng)鏈接（Keep-alive）眉反，定期從 Name Server 讀取 Topic 路由信息昙啄，并向提供 Topic 服務(wù)的 Master Broker 建立長(zhǎng)鏈接，且定時(shí)向 Master Broker 發(fā)送心跳寸五。

消費(fèi)者：與 Name Server 集群中的其中一個(gè)節(jié)點(diǎn)（隨機(jī)）建立長(zhǎng)連接梳凛，定期從 Name Server 拉取 Topic 路由信息，并向提供 Topic 服務(wù)的 Master Broker播歼、Slave Broker 建立長(zhǎng)連接伶跷，且定時(shí)向 Master Broker、Slave Broker 發(fā)送心跳秘狞。Consumer 既可以從 Master Broker 訂閱消息叭莫，也可以從 Slave Broker 訂閱消息，訂閱規(guī)則由 Broker 配置決定烁试。

RocketMQ 消息類型

RocketMQ 支持豐富的消息類型雇初，可以滿足多場(chǎng)景的業(yè)務(wù)需求。不同的消息有不同的應(yīng)用場(chǎng)景减响，下面為大家介紹常用的四種消息類型靖诗。

普通消息

普通消息是指 RocketMQ 中無(wú)特性的消息郭怪。當(dāng)沒(méi)有特殊的業(yè)務(wù)場(chǎng)景，使用普通消息就夠了刊橘。如果有特殊的場(chǎng)景鄙才，就可以使用特殊的消息類型，比如順序促绵，事務(wù)等攒庵。

同步發(fā)送

同步發(fā)送：消息發(fā)送方發(fā)送出去一條消息，會(huì)同步得到服務(wù)端返回的結(jié)果败晴。

異步發(fā)送

異步發(fā)送：消息發(fā)送方發(fā)出去一條消息浓冒，不用等待服務(wù)端返回結(jié)果，可以接著發(fā)送下一條消息尖坤。發(fā)送方可以通過(guò)回調(diào)接口接收服務(wù)端響應(yīng)稳懒，并處理響應(yīng)結(jié)果。

單向發(fā)送

單向發(fā)送：消息發(fā)送方只負(fù)責(zé)發(fā)送消息慢味，發(fā)送出去后就不管了场梆，這種方式發(fā)送速度非常快贮缕，存在丟失消息的風(fēng)險(xiǎn)辙谜。

順序消息

順序消息是指生產(chǎn)者按照一定的先后順序發(fā)布消息俺榆；消費(fèi)者按照既定的先后順序訂閱消息感昼，即先發(fā)布的消息一定會(huì)先被消費(fèi)者接收到。

比如數(shù)據(jù)分發(fā)的場(chǎng)景罐脊，如果我們訂閱了 Mysql 的 binlog 來(lái)進(jìn)行數(shù)據(jù)異構(gòu)定嗓。消息要是沒(méi)有順序，就會(huì)出現(xiàn)數(shù)據(jù)錯(cuò)亂問(wèn)題萍桌。

比如新增一條 id=1 的數(shù)據(jù)宵溅，然后馬上刪除。這樣就產(chǎn)生了兩條消息上炎。正常的消費(fèi)順序是先新增恃逻，然后刪除，此時(shí)數(shù)據(jù)是沒(méi)有的藕施。如果消息沒(méi)有順序寇损，刪除的先被消費(fèi)了，然后消費(fèi)新增的裳食，此時(shí)數(shù)據(jù)還在矛市，沒(méi)被刪除掉，就會(huì)導(dǎo)致不一致诲祸。

定時(shí)消息

定時(shí)消息是指消息具備定時(shí)發(fā)送的功能浊吏，當(dāng)消息發(fā)送到服務(wù)端后而昨，不會(huì)立即投遞給消費(fèi)者。而是要等到消息指定的時(shí)間后才會(huì)投遞給消費(fèi)者進(jìn)行消費(fèi)找田。

延遲消息也就是定時(shí)消息歌憨，定時(shí)消息是定在某個(gè)時(shí)間點(diǎn)進(jìn)行發(fā)送，比如 2020-11-11 12:00:00 發(fā)送墩衙。

延遲消息一般是在當(dāng)前發(fā)送時(shí)間的基礎(chǔ)上延遲多久進(jìn)行發(fā)送躺孝，比如當(dāng)前時(shí)間是 2020-09-10 12:00:00，延遲 10 分鐘底桂，那么消息發(fā)送成功后將在 2020-09-10 12:10:00 進(jìn)行投遞給消費(fèi)者植袍。

定時(shí)消息可以在訂單超時(shí)未支付自動(dòng)取消等場(chǎng)景使用。

事務(wù)消息

RocketMQ 提供類似 X/Open XA 的分布式事務(wù)功能籽懦，通過(guò) RocketMQ 事務(wù)消息能達(dá)到分布式事務(wù)的最終一致于个。

交互流程：

?

圖片來(lái)源阿里云官方文檔

發(fā)送方首先發(fā)送半事務(wù)消息到 RocketMQ 服務(wù)端。

RocketMQ 服務(wù)端接收到消息暮顺，然后將消息持久化成功之后厅篓，向發(fā)送方返回 Ack 確認(rèn)消息已經(jīng)發(fā)送成功，此時(shí)消息為半事務(wù)消息捶码，不會(huì)投遞給消費(fèi)方羽氮。

收到半事務(wù)消息的 Ack 后，發(fā)送方開(kāi)始執(zhí)行本地事務(wù)邏輯惫恼。

發(fā)送方根據(jù)本地事務(wù)執(zhí)行結(jié)果向服務(wù)端提交二次確認(rèn)档押，如果本地事務(wù)執(zhí)行成則進(jìn)行消息的 Commit，如果執(zhí)行失敗則進(jìn)行消息的 Rollback祈纯，服務(wù)端收到 Commit 狀態(tài)則將半事務(wù)消息標(biāo)記為可投遞令宿，消費(fèi)方最終將收到該消息；服務(wù)端收到 Rollback 狀態(tài)則刪除半事務(wù)消息腕窥，消費(fèi)方將不會(huì)收到該消息粒没。

如果出現(xiàn)意外情況，步驟 4 沒(méi)有進(jìn)行消息的二次確認(rèn)簇爆，等待固定時(shí)間后服務(wù)端將對(duì)該消息發(fā)起消息回查癞松。

發(fā)送方收到消息回查后，需要檢查對(duì)應(yīng)消息的本地事務(wù)執(zhí)行的最終結(jié)果入蛆。發(fā)送方根據(jù)檢查得到的本地事務(wù)的最終狀態(tài)再次提交二次確認(rèn)响蓉，服務(wù)端仍按照步驟 4 對(duì)半事務(wù)消息進(jìn)行操作。

最佳實(shí)踐

消息重試

消息在消費(fèi)方消費(fèi)失敗后安寺，RocketMQ 服務(wù)端會(huì)重新進(jìn)行消息的投遞厕妖，知道消費(fèi)者成功消費(fèi)消息，當(dāng)然重試有次數(shù)限制挑庶，默認(rèn) 16 次言秸。

消息重試在一定程度上保證了消息不丟失软能，通過(guò)重試來(lái)達(dá)到最終被消費(fèi)的目的。需要注意的是消費(fèi)者在消費(fèi)的時(shí)候一定要等本地業(yè)務(wù)成功后才能進(jìn)行 ACK(消費(fèi)確認(rèn))举畸，不然就會(huì)出現(xiàn)消費(fèi)失敗查排，但是已經(jīng) ACK，消息將不會(huì)重復(fù)投遞抄沮。

如果采取異步消費(fèi)的方式跋核，需要進(jìn)行異步轉(zhuǎn)同步，等異步操作完才進(jìn)行 ACK

最后需要做好對(duì)應(yīng)的監(jiān)控叛买，如果重試了 4砂代，5 次還是失敗的，基本上后面重試也是失敗的率挣。這個(gè)時(shí)候需要讓開(kāi)發(fā)人員知道刻伊，該人工處理的就人工介入〗饭Γ或者直接監(jiān)控死信隊(duì)列捶箱。

消息過(guò)濾

消息主題，一般用于一類消息的統(tǒng)一分類动漾。比如訂單主題丁屎，但是訂單下的消息會(huì)分為很多種。比如創(chuàng)建訂單旱眯，取消訂單等晨川。

不同類型的消息有不同的業(yè)務(wù)處理，我們可以統(tǒng)一定義消息格式键思，然后通過(guò)一個(gè)字段去區(qū)分消息類型來(lái)做不同的業(yè)務(wù)邏輯础爬。不好的點(diǎn)在于所有消息都會(huì)推送到消費(fèi)方，不能按需消費(fèi)吼鳞。

在 RocketMQ 中可以給消息指定 tag，通過(guò) tag 來(lái)區(qū)分消息類型叫搁。消費(fèi)者可以根據(jù) Tag 在 RocketMQ 服務(wù)端完成消息過(guò)濾赔桌，以確保消費(fèi)者最終只消費(fèi)到其關(guān)注的消息類型。

我曾經(jīng)遇到過(guò)一個(gè) tag 沒(méi)有正確使用的方式渴逻，只有一個(gè) MQ 實(shí)例疾党，用 tag 來(lái)區(qū)分環(huán)境。所有消息都在一個(gè)主題中惨奕，測(cè)試環(huán)境消費(fèi)測(cè)試環(huán)境的 tag雪位，線上消費(fèi)線上的 tag。

這種方式的問(wèn)題在于消息沒(méi)做隔離梨撞，線上線下的消息都在一起雹洗。另一個(gè)就是 tag 被固定成了環(huán)境的區(qū)分香罐，無(wú)法用于消息類型場(chǎng)景，導(dǎo)致只能建多個(gè) topic 來(lái)承載多個(gè)業(yè)務(wù)消息類型时肿。

?

消費(fèi)模式

RocketMQ 消費(fèi)模式有兩種庇茫，集群消費(fèi)和廣播消費(fèi)。

集群消費(fèi)：

?

消費(fèi)者部署了多個(gè)實(shí)例我們稱之為一個(gè)集群螃成，集群消費(fèi)只會(huì)被其中的某一個(gè)實(shí)例進(jìn)行消費(fèi)旦签。

適合大部分的業(yè)務(wù)場(chǎng)景，大部分的場(chǎng)景我們的消息只允許被消費(fèi)一次寸宏，而且只能有一個(gè)消費(fèi)者去消費(fèi)宁炫，比如支付回調(diào)場(chǎng)景，如果一個(gè)消息被多個(gè)實(shí)例同時(shí)消費(fèi)氮凝，那么就會(huì)出現(xiàn)同時(shí)去修改訂單狀態(tài)淋淀，同時(shí)去扣減庫(kù)存的情況。

廣播消費(fèi)：

?

廣播消費(fèi)會(huì)讓集群中每個(gè)實(shí)例都消費(fèi)一次覆醇。

比如我們使用了本地緩存朵纷，當(dāng)數(shù)據(jù)變更的時(shí)候，我們需要刷新每個(gè)節(jié)點(diǎn)本地的緩存永脓，所以每個(gè)節(jié)點(diǎn)都需要收到消息袍辞。

消費(fèi)冪等

冪等問(wèn)題，無(wú)論是在 API 請(qǐng)求場(chǎng)景還是在消息消費(fèi)場(chǎng)景常摧，都會(huì)遇到搅吁。一條消息不能重復(fù)消費(fèi)多次這個(gè)肯定是要保證的，因?yàn)槲覀儾荒鼙ＷC消息發(fā)送方不發(fā)送多次落午，也不能保證消息不重復(fù)投遞谎懦。

RocketMQ 的 Exactly-Once 投遞語(yǔ)義，就是用于解決冪等問(wèn)題溃斋。Exactly-Once 是指發(fā)送到消息系統(tǒng)的消息只能被消費(fèi)端處理且僅處理一次界拦，即使生產(chǎn)端重試消息發(fā)送導(dǎo)致某消息重復(fù)投遞，該消息在消費(fèi)端也只被消費(fèi)一次梗劫。

最佳的冪等處理方式還是需要有一個(gè)唯一的業(yè)務(wù)標(biāo)識(shí)享甸，雖然每條消息都有 MessageId，但是不建議用 MessageId 來(lái)做冪等判斷梳侨，在發(fā)送消息的時(shí)候蛉威，可以為每條消息設(shè)置一個(gè) MessageKey，這個(gè) MessageKey 就可以用來(lái)做業(yè)務(wù)的唯一標(biāo)識(shí)走哺。

通用的冪等實(shí)現(xiàn)方案蚯嫌。

?

本地事務(wù)消息封裝

上面介紹了事務(wù)消息，RocketMQ 的事務(wù)消息采用了二階段提交的方式。并且結(jié)合了消息反差的機(jī)制來(lái)確保最終一致性择示。

從使用層面來(lái)說(shuō)束凑，每個(gè)業(yè)務(wù)場(chǎng)景都要去實(shí)現(xiàn)一個(gè)反差的邏輯，有點(diǎn)煩对妄。

下面介紹另一種經(jīng)常被使用的方式湘今，就是本地事務(wù)消息。本地消息表這個(gè)方案最初是 ebay 提出的剪菱，本地事務(wù)消息需要在服務(wù)對(duì)應(yīng)的數(shù)據(jù)庫(kù)中創(chuàng)建一個(gè)消息表摩瞎，發(fā)送消息的時(shí)候不是真正的將消息發(fā)送給 MQ，而是往消息表中插入一條消息數(shù)據(jù)孝常。

插入的動(dòng)作跟本地的業(yè)務(wù)邏輯是同一個(gè)事務(wù)旗们，如果本地事務(wù)執(zhí)行成功，消息才會(huì)落表成功构灸，才會(huì)發(fā)送給 MQ, 本地事務(wù)失敗上渴，消息數(shù)據(jù)回滾。

然后需要有一個(gè)專門的程序去拉取消息表中未發(fā)送的消息投遞給 MQ喜颁，如果投遞失敗稠氮，可以一直重試，直到成功或者人工介入半开。

?

消息寫(xiě)到消息表隔披，然后會(huì)一直給 MQ 發(fā)送，這個(gè)步驟沒(méi)問(wèn)題寂拆。如果 MQ 收到消息后奢米，消息還在 PageCache 中的時(shí)候，Broker 宕機(jī)了纠永，這個(gè)時(shí)候是會(huì)出現(xiàn)消息丟失鬓长。當(dāng)然你也可以使用同步刷盤等方式來(lái)避免丟失。假如我們就是異步刷盤尝江，有辦法保證消息不丟失嗎涉波？

前面我們提到，RocketMQ 的事務(wù)消息會(huì)有回查的機(jī)制茂装，消息表的方式怠蹂，也需要有一個(gè)機(jī)制來(lái)保證消息被消費(fèi)了，否則就需要不斷的重試去發(fā)送消息少态，直到消息被消費(fèi)。

在消息表中需要有一個(gè)字段來(lái)標(biāo)識(shí)當(dāng)前這條消息的狀態(tài)易遣，比如 未發(fā)送彼妻，已發(fā)送，已消費(fèi)。當(dāng)消息還是未發(fā)送的時(shí)候就會(huì)被發(fā)送到 MQ, 如果發(fā)送成功了侨歉，狀態(tài)就是已發(fā)送屋摇。但是過(guò)了幾分鐘，狀態(tài)還是已發(fā)送幽邓，這個(gè)時(shí)候就要去做一些動(dòng)作了炮温。

這個(gè)場(chǎng)景下，有可能是消費(fèi)者跟不上生產(chǎn)的速度牵舵，消息堆積了柒啤，導(dǎo)致消息一直沒(méi)被消費(fèi)。另一種可能就是消息是不是丟失了畸颅？

可以獲取對(duì)應(yīng)的消息堆積數(shù)據(jù)來(lái)判斷是否消息堆積了担巩，如果不是就重新發(fā)送消息給 MQ，知道消息被消費(fèi)没炒。

問(wèn)題是消息被消費(fèi)了涛癌，我怎么知道？

像我使用的云服務(wù)送火，是有對(duì)應(yīng)的 Open API 可以直接查詢消息軌跡拳话。開(kāi)源的應(yīng)該也有，沒(méi)有仔細(xì)去研究种吸，跟商業(yè)版應(yīng)該差不多弃衍。

根據(jù)消息軌跡就可以知道消息有沒(méi)有被消費(fèi)，到此為止流程結(jié)束骨稿。消息發(fā)送給 MQ 如果失敗會(huì)重試笨鸡，消息如果長(zhǎng)時(shí)間沒(méi)消費(fèi)，也會(huì)重新發(fā)送坦冠，即使最后進(jìn)入了死信隊(duì)列形耗，也可以通過(guò)死信隊(duì)列的監(jiān)控來(lái)人工干預(yù)，一定會(huì)是最終一致性辙浑。

跟自帶的事務(wù)消息比激涤，本地消息表的方式不需要實(shí)現(xiàn)回查邏輯，但是要增加消息表判呕，同時(shí)也要配套各種發(fā)送倦踢，檢查等邏輯，也挺麻煩了侠草。特別是當(dāng)消息量大的時(shí)候辱挥，如何快速的將消息表中的消息發(fā)送出去，也需要做很多處理边涕，簡(jiǎn)單的查表輪詢?cè)诹看蟮那闆r下不太適用晤碘。

兩種方式都可以使用褂微，能實(shí)現(xiàn)我們要的目的即可。

限于篇幅的原因园爷，RocketMQ就展示一小部分宠蚂，類似于源碼和企業(yè)實(shí)戰(zhàn)的操作在這里

?

?

?

而這份資料的整理，除了RocketMQ之外童社，還有RabbitMQ求厕、ActiveMQ、Kafka以及消息隊(duì)列理論和消息協(xié)議扰楼，都是從底層源碼的層級(jí)講起

RabbitMQ

?

ActiveMQ

?

Kafka

?

不知道這份源碼+圖解的消息中間件文檔有沒(méi)有引起你的興趣呢呀癣？其實(shí)這份文檔最重要的地方就是他有很詳細(xì)的代碼解析，在學(xué)習(xí)的過(guò)程中可以自己實(shí)踐一下灭抑，查看效果十艾，起到事半功倍的效果

需要這份資料的，關(guān)注+轉(zhuǎn)發(fā)后腾节，私信“資料”即可查看獲取方式