資訊專欄INFORMATION COLUMN
摘要：將消息持久化成功之后，向發(fā)送方確認消息已經(jīng)發(fā)送成功，此時消息為半消息。發(fā)送方收到消息回查后，需要檢查對應消息的本地事務執(zhí)行的最終結果。發(fā)送方根據(jù)檢查得到的本地事務的最終狀態(tài)再次提交二次確認，仍按照步驟對半消息進行操作。
1.應用場景解耦
異步
流量消峰
日志記錄
消費端處理消息的業(yè)務邏輯保持冪等性
保證每條消息都有唯一編號且保證消息處理成功與去重表的日志同時出現(xiàn)
Producer對于需要順序的消息發(fā)送到同一個queue中
Consumer使用MessageListenerOrderly來對消息進行有序消費
發(fā)送方向 MQ 服務端發(fā)送消息。
MQ Server 將消息持久化成功之后，向發(fā)送方 ACK 確認消息已經(jīng)發(fā)送成功，此時消息為半消息。
發(fā)送方開始執(zhí)行本地事務邏輯。
發(fā)送方根據(jù)本地事務執(zhí)行結果向 MQ Server 提交二次確認（Commit 或是 Rollback），MQ Server 收到 Commit 狀態(tài)則將半消息標記為可投遞，訂閱方最終將收到該消息；MQ Server 收到 Rollback 狀態(tài)則刪除半 消息，訂閱方將不會接受該消息。
在斷網(wǎng)或者是應用重啟的特殊情況下，上述步驟4提交的二次確認最終未到達 MQ Server，經(jīng)過固定時間后 MQ Server 將對該消息發(fā)起消息回查。
發(fā)送方收到消息回查后，需要檢查對應消息的本地事務執(zhí)行的最終結果。
發(fā)送方根據(jù)檢查得到的本地事務的最終狀態(tài)再次提交二次確認，MQ Server 仍按照步驟4對半消息進行操作。
push模式：客戶端與服務端建立連接后，當服務端有消息時，將消息推送到客戶端。
pull模式：客戶端不斷的輪詢請求服務端，來獲取新的消息。
但在具體實現(xiàn)時，Push和Pull模式都是采用消費端主動拉取的方式，即consumer輪詢從broker拉取消息。
長輪詢即是在請求的過程中，若是服務器端數(shù)據(jù)并沒有更新，那么則將這個連接掛起，直到服務器推送新的 數(shù)據(jù)，再返回，然后進入循環(huán)周期。 客戶端像傳統(tǒng)輪詢一樣從服務端請求數(shù)據(jù)，服務端會阻塞請求不會立刻返回，直到有數(shù)據(jù)或超時才返回給客 戶端，然后關閉連接，客戶端處理完響應信息后再向服務器發(fā)送新的請求。
7. 消息模式DefaultMQPushConsumer實現(xiàn)了自動保存offset值以及實現(xiàn)多個consumer的負載均衡。
//設置組名
DefaultMQPushConsumer consumer = new DefaultMQPushConsumer("HAOKE_IM")
通過groupname將多個consumer組合在一起，那么就會存在一個問題，消息發(fā)送到這個組后，消息怎么分配呢？ 這個時候，就需要指定消息模式，分別有集群和廣播模式。
集群模式
同一個 ConsumerGroup(GroupName相同) 里的每 個 Consumer 只消費所訂閱消息的一部分內容， 同
一個 ConsumerGroup 里所有的 Consumer消費的內容合起來才是所訂閱 Topic 內容的整體， 從而達到
負載均衡的目的 。
廣播模式
同一個 ConsumerGroup里的每個 Consumer都 能消費到所訂閱 Topic 的全部消息，也就是一個消息會
被多次分發(fā)，被多個 Consumer消費。
// 集群模式
consumer.setMessageModel(MessageModel.CLUSTERING);
// 廣播模式
consumer.setMessageModel(MessageModel.BROADCASTING);
8. 存儲機制
8.1 消息數(shù)據(jù)的存儲
在RocketMQ中，消息數(shù)據(jù)是保存在磁盤文件中，為了保證寫入的性能，RocketMQ盡可能保證順序寫入，順序寫入的效率比隨機寫入的效率高很多。
RocketMQ消息的存儲是由ConsumeQueue和CommitLog配合完成的，CommitLog是真正存儲數(shù)據(jù)的文件，
ConsumeQueue是索引文件，存儲數(shù)據(jù)指向到物理文件的配置。
同步刷盤
在返回寫成功狀態(tài)時，消息已經(jīng)被寫入磁盤 。
具體流程是：消息寫入內存的 PAGECACHE 后，立刻通知刷盤線程刷盤，然后等待刷盤完成，刷盤線程
執(zhí)行完成后喚醒等待的線程，返回消息寫成功的狀態(tài) 。
異步刷盤
在返回寫成功狀態(tài)時，消息可能只是被寫入了內存的 PAGECACHE，寫操作的返回快，吞吐量大
當內存里的消息量積累到一定程度時，統(tǒng)一觸發(fā)寫磁盤動作，快速寫入。
broker配置文件中指定刷盤方式
flushDiskType=ASYNC_FLUSH -- 異步
flushDiskType=SYNC_FLUSH -- 同步
文章版權歸作者所有，未經(jīng)允許請勿轉載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉載請注明本文地址：http://systransis.cn/yun/7150.html
摘要：將消息持久化成功之后，向發(fā)送方確認消息已經(jīng)發(fā)送成功，此時消息為半消息。發(fā)送方收到消息回查后，需要檢查對應消息的本地事務執(zhí)行的最終結果。發(fā)送方根據(jù)檢查得到的本地事務的最終狀態(tài)再次提交二次確認，仍按照步驟對半消息進行操作。1.應用場景 解耦 異步 流量消峰 日志記錄 2.重復消息的解決方案 消費端處理消息的業(yè)務邏輯保持冪等性 保證每條消息都有唯一編號且保證消息處理成功與去重表的日志同時出現(xiàn)...
摘要：將消息持久化成功之后，向發(fā)送方確認消息已經(jīng)發(fā)送成功，此時消息為半消息。發(fā)送方收到消息回查后，需要檢查對應消息的本地事務執(zhí)行的最終結果。發(fā)送方根據(jù)檢查得到的本地事務的最終狀態(tài)再次提交二次確認，仍按照步驟對半消息進行操作。1.應用場景 解耦 異步 流量消峰 日志記錄 2.重復消息的解決方案 消費端處理消息的業(yè)務邏輯保持冪等性 保證每條消息都有唯一編號且保證消息處理成功與去重表的日志同時出現(xiàn)...
摘要：具體可以參考消息隊列之具體可以參考實戰(zhàn)之快速入門十分鐘入門阿里中間件團隊博客是一個分布式的可分區(qū)的可復制的基于發(fā)布訂閱的消息系統(tǒng)主要用于大數(shù)據(jù)領域當然在分布式系統(tǒng)中也有應用。目前市面上流行的消息隊列就是阿里借鑒的原理用開發(fā)而得。 我自己總結的Java學習的系統(tǒng)知識點以及面試問題，目前已經(jīng)開源，會一直完善下去，歡迎建議和指導歡迎Star： https://github.com/Snail...
摘要：降級往往會指定不同的級別，面臨不同的異常等級執(zhí)行不同的處理。談談你對和的認識兩者關系具體可以看公眾號阿里巴巴中間件的這篇文章獨家解讀從微服務框架到微服務生態(tài)與并不是競爭關系，作為成熟的框架，其易用性擴展性和健壯性已得到業(yè)界的認可。 該文已加入筆主的開源項目——JavaGuide（一份涵蓋大部分Java程序員所需要掌握的核心知識的文檔類項目),地址:https://github.com/...
摘要：降級往往會指定不同的級別，面臨不同的異常等級執(zhí)行不同的處理。談談你對和的認識兩者關系具體可以看公眾號阿里巴巴中間件的這篇文章獨家解讀從微服務框架到微服務生態(tài)與并不是競爭關系，作為成熟的框架，其易用性擴展性和健壯性已得到業(yè)界的認可。 該文已加入筆主的開源項目——JavaGuide（一份涵蓋大部分Java程序員所需要掌握的核心知識的文檔類項目),地址:https://github.com/...
閱讀 769·2023-04-25 19:43
閱讀 4022·2021-11-30 14:52
閱讀 3855·2021-11-30 14:52
閱讀 3909·2021-11-29 11:00
閱讀 3838·2021-11-29 11:00
閱讀 3949·2021-11-29 11:00
閱讀 3613·2021-11-29 11:00
閱讀 6310·2021-11-29 11:00
