訊息佇列都應用到了哪些實際的應用場景中？
一、再談訊息佇列的應用場景
1、異步處理：例如短信通知、終端狀態推送、App推送、用戶注冊等
2、資料同部：業務資料推送同步
3、重試補償：記賬失敗重試
4、系統解耦：通訊上下行、終端例外監控、分布式事件中心
5、流量削峰：秒殺場景下的下單處理
6、發布訂閱：HSF的服務狀態變化通知、分布式事件中心
7、高并發緩沖：日志服務、監控上報
但是，我們對訊息佇列的底層技術和原理還是不了解，那么我們馬上開始吧，
二、訊息佇列的一些基本概念和簡單原理
1、Broker
Broker的概念來自于Apache ActiveMQ，通俗的講就是MQ的服務器，
2、訊息的生產者、消費者
訊息生產者Producer：發送訊息到訊息佇列，
訊息消費者Consumer：從訊息佇列接收訊息，
3、點對點訊息佇列模型
訊息生產者向一個特定的佇列發送訊息，訊息消費者從該佇列中接收訊息；訊息的生產者和消費者可以不同時處于運行狀態，每個成功處理的訊息都由訊息消費者簽收確認（Acknowledge），如圖：
4、發布訂閱訊息模型-Topic
發布訂閱訊息模型中，支持向一個特定的主題Topic發布訊息，0個或多個訂閱者接收來自這個主題的訊息，這種情模型下，發布者和訂閱者閉此不知道對方，實際操作程序中，必須先訂閱，再發送訊息，而后接收訂閱的訊息，這個順序必須保證，
5、訊息的順序性保證
基于Queue訊息模型，利用FIFO先進先出的特性，可以保證訊息的順序性，
6、訊息的ACK確認機制
即訊息的Acknowledge確認機制
為了確保訊息不丟失，訊息佇列提供了訊息Acknowledge機制，即ACK機制，當Consumer確認訊息已經被消費者處理，發送一個ACK給訊息佇列，此時訊息佇列便可以洗掉這個 訊息了，如果Consumer宕機/關閉，沒有發送ACK，訊息佇列講人為這個訊息沒有被處理，會將這個訊息發送給其他的Consumer重新訊息處理，
7、訊息的持久化
訊息的持久化，對于一些關鍵的核心業務來說是非常重要的，啟用訊息持久化后，訊息佇列宕機重啟后，訊息而已從持久化存盤恢復，訊息不丟失，可以繼續消費處理，
8、訊息的同部和異步收發
同部：訊息的收發支持同步收發的方式，
同時還有另一種同步方式：同步收發場景下，訊息生產者和消費者雙向應答模式，例如：張三寫封信松道郵局中轉站，然后李四從中轉站獲得信，然后在寫一份回執信，放到中轉站，然后張三去取，當然張三寫信的時候就得寫明回信地址，
訊息的接收如果以同步的方式（Pull）進行接收，如哦佇列中為空，此時接收處于同步阻塞狀態，會一直等待，直到訊息的到達，
異步：消費的收發同樣支持異步方式：異步發送 訊息，不需要等待訊息佇列的接收確認；異步接收訊息，以Push的方式觸發訊息消費者接收訊息，
9、訊息的事務支持
訊息的收發處理支持事務，例如：在任務中心場景中，一次處理可能處理涉及多個訊息的接收、處理，這處于同一個事務范圍內，如果一個訊息處理失敗，事務回滾，訊息重新回到佇列中，
三、我們對訊息佇列的實際使用
我在實際的專案中，使用過兩種訊息佇列組件：
RabbitMQ：高可用、高可靠訊息應用場景，例如記賬失敗重試、通知服務，訊息不允許丟
Kafka：高性能訊息應用場景，例如日志、監控、訊息允許丟失，
在此之上，我們封裝了訊息應用中心，日志服務等核心組件和服務，那么，訊息應用中心和日志都用到了訊息佇列什么技術？干活來了……
1、訊息應用中心
訊息應用中心（任務中心）使用了訊息佇列的異步處理、資料同步、重試補償、系統解耦、流量削峰等特性，其中：訊息應用中心（任務中心），支持RabbitMQ和Kafka兩種訊息通道，支持在任務元資料層面設定
任務：就是一個包含了任務執行背景關系的訊息，同時代表了異步處理
任務發送者（ITaskSender）發送任務：訊息的生產者將任務訊息發送到訊息佇列
任務型別：訊息佇列名稱，例如：HaKeepAcco***Queue，充電補償記賬佇列
訊息佇列：任務的臨時存盤
任務中心：任務計中處理，訊息消費者
任務處理完成：訊息Ack確認
任務的多級重試：多個重試訊息佇列，HaSysTaskStore2Queue
2、日志組件
日志組件，使用了訊息佇列的高并發緩沖和發布訂閱特性，其中：日志組件使用Kafka作為訊息通道，因為Kafka的性能號，吞吐量大，可以容忍偶爾的訊息資料丟失，日志組件使用發布訂閱的訊息模型，日志組件包含日志服務SDK和日志HSF服務，二者都是訊息的生產者Producer，日志型別：訊息的Topic主題，日志處理器：訊息的消費者、Topic的訂閱、日志資料處理（Hbase\ES\其他）
3、RPC服務狀態變化通知
RPC服務狀態變化通知，使用了訊息佇列的發布訂閱特性，其中：RPC服務狀態變化通知，使用RobbitMQ訊息佇列技術，使用發布訂閱的訊息模型，Topic：RPCServiceState，RPCService.Proxy：RPC服務狀態變化訊息的訂閱者，RPC服務注冊、發布：訊息的生產者，發送RPC服務狀態變化訊息，
四、訊息佇列使用的最佳實踐
1、RabbitMQ的鏈接，底層都是Socket鏈接，長連接 or 短鏈接？
RabbitMQ在創建每個鏈接的同時，會自動創建一個監控執行緒來定時（默認60s）偵測鏈接的狀態，如果鏈接斷開，觸發ConnectionShutdown事件，
用長連接，還是用短連接？
發送端：建議使用短連接，用完即釋放，避免長連接帶來的埠占用，因為發送端無處不在，發送操作短而急促，
接收端：建議使用長連接，時刻接收處理訊息，因為訊息的接收消費比較集中，接收操作久而彌堅，
2、網路是有抖動的，連接的斷開是正常的，如何應對？
發送端：發送失敗重試
接收端：注冊ConnectionShutdown事件同時捕獲訊息接收例外，重新建立連接，接收消費訊息，
3、RabbitMQ Exchange（Topic）模式下帶來的訊息佇列數量激增
只是創建了一個Exchange（Topic），為什么會增加這么多Queue，以為，每個Topic的訂閱都是系結一個Queue用作訊息的消費，
4、需求的演變，訊息結構的改變，如何平滑過渡？
訊息是byte[]陣列，我們將復雜物件訊息二進制序列化，接收到訊息后，我們將二進制陣列反序列化為物體類，當我們的物體類訊息體的結構發生變化后，因為受到二進制學歷惡化處理的影響，導致無法反序列化，
解決方案：
訊息體預留一些string型別的擴展欄位，
訊息佇列版本化，支持多個版本的訊息體，
5、Kafka Conusmer Group
同一個Topic的一條訊息只能被同一個Group內的一個Consumer消費，多個Consumer Group可同時消費同一個訊息，
6、訊息的擠壓
訊息的擠壓產生的原因：訊息接收消費的速率低，發送的速度>接收的速度，
訊息積壓后得影響：
訊息大量積壓后，當新得消費者連接上MQ并開始接收訊息時，發送速率會大幅降低，訊息佇列集群得壓力增加，大量得訊息要持久化存盤和同步，
如何減少訊息擠壓：快速消費訊息，同時保持訊息體不要過大，
這次的MQ相關知識先分享到這里，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/4526.html
標籤：架構設計