如何保證消息不重複 |
1、消費端處理消息的業務邏輯保持冪等性或者藉助redis等其他產品進行去重處理。更加通用的方法是,給你的數據增加一個版本號屬性,每次更數據前,比較當前數據的版本號是否和消息中的版本號一致,如果不一致就拒絕更新數據,更新數據的同時 將版本號+1,一樣可以實現冪等更新 2、保證每條消息都有唯一編號且保證消息處理成功與去重表的日誌同時出現。 |
https://blog.csdn.net/sinat_27143551/article/details/88222657 |
RabbitMQ教程 |
fanout direct topic headers |
https://blog.csdn.net/hellozpc/article/details/81436980
|
kafka分區數和消費者數關係 |
如果你的分區數是N,那麼最好線程數也保持爲N,這樣通常能夠達到最大的吞吐量。超過N的配置只是浪費系統資源,因爲多出的線程不會被分配到任何分區。 |
|
各個消息中間件的比較 |
RabbitMQ 一個比較有特色的功能是支持非常靈活的路由配置,和其他消息隊列不同的是,它在生產者(Producer)和隊列(Queue)之間增加了一個 Exchange 模塊,你可以理解爲交換機。 爲當客戶端發送一條消息的時候,Kafka 並不會立即發送出去,而是要等一會兒攢一批再發送 Kafka 的消費者讀取消息是可以重演的(replayable)。 |
https://blog.csdn.net/wqc19920906/article/details/82193316
|
消息隊列的推拉模型 |
RabbitMQ消費端爲推模型 Kafka爲拉模型 |
|
kafka丟消息 |
1、在生產階段,你需要捕獲消息發送的錯誤,並重發消息。事務型 Producer 能夠保證將消息原子性地寫入到多個分區中。這批消息要麼全部寫入成功,要麼全部失敗。另外,事務型 Producer 也不懼進程的重啓。Producer 重啓回來後,Kafka 依然保證它們發送消息的精確一次處理。 設置了 acks=all ,一定不會丟,要求是,你的 leader 接收到消息,所有的 follower 都同步到了消息之後,才認爲本次寫成功了 2、在存儲階段,你可以通過配置刷盤和複製相關的參數,讓消息寫入到多個副本的磁盤上,來確保消息不會因爲某個 Broker 宕機或者磁盤損壞而丟失。 3、在消費階段,你需要在處理完全部消費業務邏輯之後,再發送消費確認。 |
http://svip.iocoder.cn/Kafka/Interview/#Kafka-是否會弄丟數據? https://time.geekbang.org/column/article/103974
|
解決kafka消息堆積問題 |
消息積壓處理: 1、發送端優化,增加批量和線程併發兩種方式處理 2、消費端優化,優化業務邏輯代碼、水平擴容增加併發並同步擴容分區數量 查看消息積壓的方法: 1、消息隊列內置監控,查看發送端發送消息與消費端消費消息的速度變化 2、查看日誌是否有大量的消費錯誤 3、打印堆棧信息,查看消費線程卡點信息 |
|
kafka重平衡rebalance機制 |
觸發時機: ● 組成員個數發生變化。例如有新的 consumer 實例加入該消費組或者離開組。 ● 訂閱的 Topic 個數發生變化。 ● 訂閱 Topic 的分區數發生變化。 |
|
rocketMQ實現精確一次投遞 |
||
RabbitMQ解決消息丟失問題 |
生產者:開啓生產者事務或者confirm模式 broker:開啓持久化(queue持久化+消息持久化) 消費者:手動ack |
http://svip.iocoder.cn/RabbitMQ/Interview/#RabbitMQ-是否會弄丟數據? |