1.建立queue的時候設定持久化，保證broker持久化queue的元資料，但是不會持久化queue裡面的訊息
2.將message的deliverymode設定為2，可以將訊息持久化到磁碟，這樣只有message支援化到磁碟之後才會傳送通知producer ack
這兩步過後，即使broker掛了，producer肯定收不到ack的，就可以進行重發
整體流程：
整體流程：
相比第一種方案，這裡減少了一次message入庫，confirm機制是訊息可靠性投遞的乙個核心，在下篇文章會講到
首先，無論是rabbitmq、rocketmq還是kafka，都有可能出現訊息的重**送，這個是mq無法保障的，而冪等性是開發或者運維人員需要保證的
所謂訊息的冪等性是指即使收到多次訊息，也不會重複消費，這點很重要，例如使用者付錢，點的太快了，付了多次，但是你也只能扣一次錢
在consumer端offset沒有提交的時候，consumer重啟了，這時候就會出現重複消費的情況
整體實現相對簡單，需要進行資料庫寫入，利用資料庫主鍵去重，使用id進行分庫分表演算法路由，從單庫的冪等性到多庫的冪等性
redis的實現效能比較好，而且redis一般使用集群，不用擔心某台機器掛掉了，影響服務。
存在的問題：是否要進行資料落庫，如果落庫的話，怎麼保證快取和storage的一致性、事務，如果不落庫，如何設定定時同步
TCP 保證傳輸可靠性
tcp協議保證資料傳輸可靠性的方式主要有 計算方式 在資料傳輸的過程中，將傳送的資料段都當做乙個16位的整數。將這些整數加起來。並且前面的進製不能丟棄，補在後面，最後取反，得到校驗和。傳送方 在傳送資料之前計算檢驗和，並進行校驗和的填充。接收方 收到資料後，對資料以同樣的方式進行計算，求出校驗和，與...
Kafka如何保證訊息的可靠性傳輸
1.消費端弄丟了資料 唯一可能導致消費者弄丟資料的情況，就是說，你消費到了這個訊息，然後消費者那邊自動提交了 offset，讓 kafka 以為你已經消費好了這個訊息，但其實你才剛準備處理這個訊息，你還沒處理，你自己就掛了，此時這條訊息就丟咯。這不是跟 rabbitmq 差不多嗎，大家都知道 kaf...
Kafka如何保證訊息的可靠性傳輸
1.消費端弄丟了資料 在 kafka 服務端設定min.insync.replicas引數 這個值必須大於 1，這個是要求乙個 leader 至少感知到有至少乙個 follower 還跟自己保持聯絡，沒掉隊，這樣才能確保 leader 掛了還有乙個 follower 吧。在 producer 端設定...