摘要：將消息持久化成功之后，向發(fā)送方確認(rèn)消息已經(jīng)發(fā)送成功，此時(shí)消息為半消息。發(fā)送方收到消息回查后，需要檢查對(duì)應(yīng)消息的本地事務(wù)執(zhí)行的最終結(jié)果。發(fā)送方根據(jù)檢查得到的本地事務(wù)的最終狀態(tài)再次提交二次確認(rèn)，仍按照步驟對(duì)半消息進(jìn)行操作。

解耦

異步

流量消峰

日志記錄

消費(fèi)端處理消息的業(yè)務(wù)邏輯保持冪等性

保證每條消息都有唯一編號(hào)且保證消息處理成功與去重表的日志同時(shí)出現(xiàn)

Producer對(duì)于需要順序的消息發(fā)送到同一個(gè)queue中

Consumer使用MessageListenerOrderly來對(duì)消息進(jìn)行有序消費(fèi)

發(fā)送方向 MQ 服務(wù)端發(fā)送消息。

MQ Server 將消息持久化成功之后，向發(fā)送方 ACK 確認(rèn)消息已經(jīng)發(fā)送成功，此時(shí)消息為半消息。

發(fā)送方開始執(zhí)行本地事務(wù)邏輯。

發(fā)送方根據(jù)本地事務(wù)執(zhí)行結(jié)果向 MQ Server 提交二次確認(rèn)（Commit 或是 Rollback），MQ Server 收到 Commit 狀態(tài)則將半消息標(biāo)記為可投遞，訂閱方最終將收到該消息；MQ Server 收到 Rollback 狀態(tài)則刪除半 消息，訂閱方將不會(huì)接受該消息。

在斷網(wǎng)或者是應(yīng)用重啟的特殊情況下，上述步驟4提交的二次確認(rèn)最終未到達(dá) MQ Server，經(jīng)過固定時(shí)間后 MQ Server 將對(duì)該消息發(fā)起消息回查。

發(fā)送方收到消息回查后，需要檢查對(duì)應(yīng)消息的本地事務(wù)執(zhí)行的最終結(jié)果。

發(fā)送方根據(jù)檢查得到的本地事務(wù)的最終狀態(tài)再次提交二次確認(rèn)，MQ Server 仍按照步驟4對(duì)半消息進(jìn)行操作。

push模式：客戶端與服務(wù)端建立連接后，當(dāng)服務(wù)端有消息時(shí)，將消息推送到客戶端。

pull模式：客戶端不斷的輪詢請(qǐng)求服務(wù)端，來獲取新的消息。

但在具體實(shí)現(xiàn)時(shí)，Push和Pull模式都是采用消費(fèi)端主動(dòng)拉取的方式，即consumer輪詢從broker拉取消息。

長(zhǎng)輪詢即是在請(qǐng)求的過程中，若是服務(wù)器端數(shù)據(jù)并沒有更新，那么則將這個(gè)連接掛起，直到服務(wù)器推送新的 數(shù)據(jù)，再返回，然后進(jìn)入循環(huán)周期。 客戶端像傳統(tǒng)輪詢一樣從服務(wù)端請(qǐng)求數(shù)據(jù)，服務(wù)端會(huì)阻塞請(qǐng)求不會(huì)立刻返回，直到有數(shù)據(jù)或超時(shí)才返回給客 戶端，然后關(guān)閉連接，客戶端處理完響應(yīng)信息后再向服務(wù)器發(fā)送新的請(qǐng)求。

DefaultMQPushConsumer實(shí)現(xiàn)了自動(dòng)保存offset值以及實(shí)現(xiàn)多個(gè)consumer的負(fù)載均衡。

//設(shè)置組名
DefaultMQPushConsumer consumer = new DefaultMQPushConsumer("HAOKE_IM")

通過groupname將多個(gè)consumer組合在一起，那么就會(huì)存在一個(gè)問題，消息發(fā)送到這個(gè)組后，消息怎么分配呢？ 這個(gè)時(shí)候，就需要指定消息模式，分別有集群和廣播模式。

集群模式
同一個(gè) ConsumerGroup(GroupName相同) 里的每 個(gè) Consumer 只消費(fèi)所訂閱消息的一部分內(nèi)容， 同 一個(gè) ConsumerGroup 里所有的 Consumer消費(fèi)的內(nèi)容合起來才是所訂閱 Topic 內(nèi)容的整體， 從而達(dá)到 負(fù)載均衡的目的 。

廣播模式
同一個(gè) ConsumerGroup里的每個(gè) Consumer都 能消費(fèi)到所訂閱 Topic 的全部消息，也就是一個(gè)消息會(huì) 被多次分發(fā)，被多個(gè) Consumer消費(fèi)。

// 集群模式
consumer.setMessageModel(MessageModel.CLUSTERING);
// 廣播模式
consumer.setMessageModel(MessageModel.BROADCASTING);

在RocketMQ中，消息數(shù)據(jù)是保存在磁盤文件中，為了保證寫入的性能，RocketMQ盡可能保證順序?qū)懭?，順序?qū)懭氲男时入S機(jī)寫入的效率高很多。
RocketMQ消息的存儲(chǔ)是由ConsumeQueue和CommitLog配合完成的，CommitLog是真正存儲(chǔ)數(shù)據(jù)的文件， ConsumeQueue是索引文件，存儲(chǔ)數(shù)據(jù)指向到物理文件的配置。

同步刷盤
在返回寫成功狀態(tài)時(shí)，消息已經(jīng)被寫入磁盤 。 具體流程是：消息寫入內(nèi)存的 PAGECACHE 后，立刻通知刷盤線程刷盤，然后等待刷盤完成，刷盤線程 執(zhí)行完成后喚醒等待的線程，返回消息寫成功的狀態(tài) 。

異步刷盤
在返回寫成功狀態(tài)時(shí)，消息可能只是被寫入了內(nèi)存的 PAGECACHE，寫操作的返回快，吞吐量大 當(dāng)內(nèi)存里的消息量積累到一定程度時(shí)，統(tǒng)一觸發(fā)寫磁盤動(dòng)作，快速寫入。

broker配置文件中指定刷盤方式
flushDiskType=ASYNC_FLUSH -- 異步
flushDiskType=SYNC_FLUSH -- 同步