訊息佇列介紹
本文將介紹大名鼎鼎的訊息佇列（MQ）的原理，應用場景和常見問題。
日常開發中，可能會經常遇到這幾類問題：
- 系統中批量更新（增，刪，改）功能介面，如果業務比較複雜，加之資料量龐大，這類同步操作是很耗時的，這時候需要進行非同步處理。
- 電子商務網站在促銷活動時，會在短時間內高併發，需要削平高峰期的併發事務。
- 為了提高系統的可擴充套件性，希望各個模組之間不存在直接呼叫，開發低耦合的系統，對各個模組之間進行解耦。
以上場景，都可以使用訊息佇列有效解決。
什麼是訊息佇列？
訊息(Message)是指在應用間傳送的資料（比如字串，json等），訊息佇列（Message Queue，簡稱MQ）是一個古老的計算機術語，UNIX程序間通訊就用到了訊息佇列技術：一個程序把資料寫入某個特定佇列中，其它佇列讀取特定佇列中的資料實現非同步通訊。而現在我們所說的MQ通常指的是獨立的訊息佇列中介軟體，利用高效可靠的訊息傳遞機制進行與平臺無關的資料交流，並基於資料通訊來進行分散式系統的整合。
傳遞模式
訊息佇列一般有兩種傳遞模式：
- 點對點（Point to Point，簡稱PTP）：訊息生產者傳送訊息到佇列，消費者從佇列中接收訊息。訊息被消費以後，queue中不再儲存，queue支援存在多個消費者，但是一個訊息只能被一個消費者消費。
- 釋出 / 訂閱（Pub / Sub）：釋出訂閱（一對多）廣播形式，訊息釋出者將訊息釋出到某個主題(Topic），訊息訂閱者從主題中訂閱訊息（得到訊息的拷貝），一個訊息可以同時被多個消費者訂閱，並會被所有訂閱者消費。
組成
- Broker: 訊息伺服器，作為server提供訊息核心服務
- Producer：訊息生產者，業務的發起方，生產訊息傳輸給broker
- Consumer：訊息消費者，業務處理方，負責從broker獲取訊息並進行業務邏輯處理
- Topic：主題，Pub/sub模式下 訊息統一匯聚地，不同生產者向topic傳送訊息，由MQ伺服器分發到不同訂閱者，實現訊息的廣播。
- Queue：佇列，PTP模式下，特定生產者向特定佇列傳送訊息，消費者訂閱特定的queue完成指定訊息的接收與消費。
- Message：訊息體，根據不同通訊協議定義的固定格式編碼資料包，來封裝業務資料，實現訊息的傳輸。
訊息佇列的作用
介紹幾個訊息佇列的重要作用：
- 解耦：傳統的軟體開發模式，各個模組之間相互呼叫，資料共享，每個模組都要時刻關注其他模組的是否更改或者是否掛掉等等，使用訊息佇列，可以避免模組之間直接呼叫，將所需共享的資料放在訊息佇列中，對於新增業務模組，只要對該類訊息感興趣，即可訂閱該類訊息，對原有系統和業務沒有任何影響，降低了系統各個模組的耦合度，提高了系統的可擴充套件性。
- 非同步：訊息佇列提供了非同步處理機制，在很多時候應用不想也不需要立即處理訊息，允許應用把一些訊息放入訊息中介軟體中，並不立即處理它，在之後需要的時候再慢慢處理。
- 削峰：在訪問了驟增的場景下，需要保證應用系統的平穩性，但是這樣突發流量並不常見，如果以這類峰值的標準而投放資源的話，那無疑是巨大的浪費，使用訊息佇列能夠使關鍵元件支撐突發訪問壓力，不會因為突發的超負荷請求而完全崩潰。訊息佇列的容量可以配置的很大，如果採用磁碟儲存訊息，則幾乎等於“無限”容量，這樣一來，高峰期的訊息可以被積壓起來，在隨後的時間內進行平滑的處理完成，而不至於讓系統短時間內無法承載而導致崩潰，在電商網站的秒殺搶購這種突發性流量很強的業務場景中，訊息佇列的強大緩衝能力可以很好的起到削峰作用。
訊息佇列技術選型
現在有很多主流的訊息中介軟體，包括：ActiveMQ, RabbitMQ，Kafka, RocketMQ，Redis。選型時要結合具體的應用場景和自身的業務需求，從功能、效能、運維、可靠性+可用性等維度進行多重考量。
ActiveMQ
Apache出品，Java開發，目前所佔的市場份額不多。
RabbitMQ
Erlang語言實現AMQP協議的訊息中介軟體，併發能力很強，效能及其好，延時很低（達到微妙級），特點：可靠性，可用性，擴充套件性，功能豐富。
Kafka
LinkedIn使用Scala開發的分散式，多分割槽，多副本且基於zookeeper協調的分散式訊息系統，提供了超高的吞吐量，毫秒級延遲，極高的可用性和可靠性。
RocketMQ
阿里出品，Java開發，高吞吐，高可用，適合大規模分散式應用，經過多次雙十一的洗禮，實力不容小覷。
所謂的訊息中介軟體大道至簡：一發一存一消費，沒有最好的訊息中介軟體，只有最合適的訊息中介軟體。
帶來的問題
引入訊息佇列後，我們需要考慮哪些問題呢？
1. 訊息堆積
這是一個很常見的問題，如果訊息消費的時間太久，或者伺服器故障，導致訊息堆積。
2. 訊息丟失
訊息堆積一個處理方案就是給訊息加上超時時間判定，這樣就會衍生一個問題，當訊息堆積，處理完成之後，就會存在一定訊息的丟失，或者伺服器宕機也會導致訊息丟失，需要針對此類問題做好應對方案。
3. 訊息準確消費
保證訊息被準確消費，且不存在重複消費的問題。
以上。
最後，祝大家新年快樂