訊息佇列
解耦
A服務和多個服務耦合，內部維護對多個服務發送資料的介面，那么這些介面如果有的掛了，有的不需要了，那么還得修改A內部的代碼，如果使用MQ，A發送訊息就好，不必考慮那么多事情，
通過一個 MQ，Pub/Sub 發布訂閱訊息這么一個模型，A 系統就跟其它系統徹底解耦了
異步
不需等待整個業務流程走完，把業務需要走的流程發送到MQ，其他服務進行消費走完接下來的流程即可
削峰
對短時間的大量請求進行佇列內的訊息堆積，等待服務進行能力范圍內的消費
高可用（RabbitMQ）
三種模式：單機，普通集群，鏡像集群
單機：玩具
普通集群：多個機器，創建的佇列只會存放在一個實體上，其他實體還得拉取資料，造成了集群內部的大量流量消耗，而且佇列所在節點宕機，資料就丟了，做不到高可用，但是吞吐量會高一點
鏡像集群：創建的佇列就會存放在多個實體上，每次寫訊息都會同步到所有實體 ， 缺點：沒有擴展性（queue多了，加機器也沒用，因為每個機器上都有完整的資料），性能開銷大
Kafka（天然分布式）
每個機器放一部分資料，每個節點內的資料都會有副本，同步到其他機器上，然后選舉出一個leader，生產和消費都和他打交道
生產和消費都在所有的follower同步好回傳ack之后訊息佇列才回傳操作成功
如何保證訊息不被重復消費/如何保證訊息消費的冪等性
原因：kafka為例：一條訊息消費后會提交offset，下一次消費會從offset后面的資料進行消費，如果消費者行程重啟，那么消費過的offset就沒有上交，就會導致重復消費
重復消費不可怕，可怕的是沒考慮到重復消費之后，怎么保證冪等性，
生產者發送資料時，加一個全域唯一的id，消費時查一下redis是否消費過
如何保證訊息的可靠性傳輸/如何處理訊息丟失的問題
RabbitMQ
生產者弄丟了資料
解決方案：1. 事務機制（耗性能，因為是同步）2. confirm機制（性能號，異步），生產者開啟confirm模式，發送的訊息分配一個唯一的id，如果送達rabbitmq，會回傳一個ack訊息，如果送達失敗，則會回呼一個nack介面，告知接受失敗
訊息佇列弄丟了資料
解決方案：訊息佇列進行持久化：1. 創建佇列時進行持久化，2. 發送訊息時吧引數設定為持久化
但是訊息佇列還沒進行持久化就掛了咋辦：結合confirm，持久化成功之后再回傳ack，如果沒有持久化那么生產者是可以進行重發的，
消費者弄丟了資料
關閉自動ack，自己消費后再手動回傳ack使訊息佇列洗掉訊息，如果沒有回傳ack，訊息佇列就把訊息分配給別的消費者處理，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/500593.html
標籤：架構設計
上一篇：從業務開發中學習和理解架構設計