我們在開發軟件的時候，經常會用到消息隊列，憑藉其自身的特點，可以在滿足業務需求的前提下，一定程度上系統的抗壓性，但是消息隊列使用不當或者是選擇不當，效果可能不會那麼好，所以我們有必要了解消息隊列的優缺點。
1、優點：解耦、異步、削峯
解耦：解除倆個系統的耦合度，憑藉中間層，減少倆個系統直接調用的耦合度。
異步：系統直接的調用由同步變成了異步，例如系統A、B、C，系統生產的消息不僅可以提供給B系統，還可以擴展到C系統，我生產者A不需要修改代碼邏輯，只負責生產消息，而且生產者不關心你是否有沒有消費、啥時候消費；而消費B和C，我們只需要訂閱生產的消息，到時候消費消息即可，有消息就消費。
削峯：當流量出現急劇上升，系統的處理能力達到瓶頸的時候，通過消息隊列，逐漸放行消息，減緩系統的處理頻率，從而不至於將系統的CPU耗盡，從而使請求依次處理，達到削峯效果。
但是消息隊列也存在一些缺點
2、缺點：系統可用性降低、系統複雜度提高、數據一致性等問題
系統可用性降級：既然在系統中引入第三方，就像是婚姻中引入第三者一樣，你要處理好家庭和第三者之間的平衡，否者家庭系統就會崩塌，其實系統也是如此，如果消息中間件宕機，或者中間件出現網絡波動等異常情況，下面的消費者系統就會出現數據異常，如果系統中只有AB系統，可能這樣的問題不會發生或者發生的頻率很低，但是消息中間件從當中間層，我們需要關注的系統多了一個。
系統複雜度提高：這個很好理解，以前由系統A、B、C組成，現在變成A、B、C、消息中間件組成，要考慮消息中間件的一系列問題，如高可用、異常情況等。
數據一致性問題：如果消息中間件出現當機，消費者無法成功消費消息，導致消息遺漏，從而發生消息不一致的問題。
3、我們經常用到的消息隊列有一下幾種：Kafka、ActiveMQ、RabbitMQ、RocketMQ，下圖爲各自的特點：
| 特性 | ActiveMQ | RabbitMQ | RocketMQ | Kafka |
|---|---|---|---|---|
| 單機吞吐量 | 萬級，比 RocketMQ、Kafka 低一個數量級 | 同 ActiveMQ | 10 萬級，支撐高吞吐 | 10 萬級，高吞吐，一般配合大數據類的系統來進行實時數據計算、日誌採集等場景 |
| topic 數量對吞吐量的影響 | topic 可以達到幾百/幾千的級別，吞吐量會有較小幅度的下降，這是 RocketMQ 的一大優勢，在同等機器下，可以支撐大量的 topic | topic 從幾十到幾百個時候，吞吐量會大幅度下降，在同等機器下，Kafka 儘量保證 topic 數量不要過多，如果要支撐大規模的 topic，需要增加更多的機器資源 | ||
| 時效性 | ms 級 | 微秒級，這是 RabbitMQ 的一大特點，延遲最低 | ms 級 | 延遲在 ms 級以內 |
| 可用性 | 高，基於主從架構實現高可用 | 同 ActiveMQ | 非常高，分佈式架構 | 非常高，分佈式，一個數據多個副本，少數機器宕機，不會丟失數據，不會導致不可用 |
| 消息可靠性 | 有較低的概率丟失數據 | 基本不丟 | 經過參數優化配置，可以做到 0 丟失 | 同 RocketMQ |
| 功能支持 | MQ 領域的功能極其完備 | 基於 erlang 開發，併發能力很強，性能極好，延時很低 | MQ 功能較爲完善，還是分佈式的，擴展性好 | 功能較爲簡單，主要支持簡單的 MQ 功能，在大數據領域的實時計算以及日誌採集被大規模使用 |
4、高可用框架
1）Kafka
Kafka基本框架是由多個broker組成，一個broker也就是一個節點。當創建一個主題Topic，會將Topic分成多個partition，一個partition分佈在一個broker，Kafka在8.0對框架進行優化，支持複製，即每個broker可以複製多個，由選舉產生leader，假如leader宕機後，從存活的follower中選舉出leader，保證了系統的高可用。消費者讀消息直接讀leader，生產者生產消息即對消息隊列寫，操作leader，leader在同步到follower，保持leader的數據與followew保持一致。
2）RabbitMQ
RabbitMQ的HA框架是由多個RabbitMQ實例組層，也就是部署多個相同的RabbitMQ，當創建一個queue，不論是元數據還是queue中的數據都會存在多個實例上；用戶沒次寫queue，RabbitMQ都會將數據同步到其他實例上。優點是假如某個實例宕機了，沒關係，其他實例還存在相同的數據，進而實現了HA。缺點是，我沒次寫入的數據都會同步到其他實例上，將導致網絡帶寬壓力和消耗很大以及它的框架不是分佈式的，擴展性很差，假如某個queue很大，你加機器也解決不了，它還會將該queue同步到新加的機器上，如果這個queue大到你服務器無法存下的程度了，那就很危險了。
5、Kafka實現高吞吐量的機制：
1）吞吐量：單位時間內發送的數據量。
2）高吞吐量--》儘量少垃圾回收或者不對該部分內存進行gc + 足夠大的內存--》kafka採用緩存池機制。
3）客戶端發送數據，先到kafka緩衝中，多條數據組成一個Batch或多個Batch發送給kafka服務器。
4）緩衝池機制：將整個內存分成若干個大小相同的內存塊，如果需要創建一個新的Batch，則從緩衝池中拿出一塊內存，一個或者多個Batch發送給kafka服務器後，該Batch內存歸還給緩衝池。