發送丟失 　　我們發送消息時，broker寫入到cache后就返回成功了，而producer只要獲取到ACK就說明消息發送成功了，反之肯定會收到一個異常，比如網絡錯誤、請求超時之內的。而當我們發送失敗后一直重試發送，能保證消息一定到達MQ嗎？比如這樣： 　　 　　本地事務執行完之后、數據庫 ...

前言 上篇文章，王子通過一個小案例和小伙伴們一起分析了一下消息是如何丟失的，但沒有提出具體的解決方案。 我們已經知道發生消息丟失的原因大體上分為三個部分： 1.生產者發送消息到MQ這一過程導致消息丟失 2.MQ自己發生故障導致消息丟失 3.消費者拿到消息后，由於操作不當導致消息丟失 ...

一、消息發送過程 我們將消息流程分為如下三大部分，每一部分都有可能會丟失數據。 生產階段：Producer通過網絡將消息發送給Broker，這個發送可能會發生丟失，比如網絡延遲不可達等。 存儲階段：Broker肯定是先把消息放到內存的，然后根據刷盤策略持久化到硬盤中，剛收到 ...

以上任一階段都可能會丟失消息，我們只要找到這三個階段丟失消息原因，采用合理的辦法避免丟失，就可以徹底 ...

說白了，同步發送，同步落盤 ...

https://blog.csdn.net/leeasony/article/details/104857576 ...

前言 通過之前文章的閱讀，有關RocketMQ的底層原理相信小伙伴們已經有了一個比較清晰的認識。 那么接下來王子想跟大家討論一個話題，如果我們的項目中引入了MQ，勢必要面對的一個問題，就是消息丟失問題，今天我們就來聊聊消息是怎么丟失的。 現在假設我們的業務是這樣的，用戶通過訂單系統下了 ...

1、消息整體處理過程 這里我們將消息的整體處理階段分為3個階段進行分析： Producer發送消息階段。 Broker處理消息階段 ...