訊息佇列MQ簡介

專案中要用到rabbitmq，領導讓我先了解一下。在之前的公司中，用到過訊息佇列mq，阿里的那款rocketmq，當時公司也做了簡單的技術分享，自己也看了一些部落格。自己在有道雲筆記上，做了一些整理，但後來也就擱在那了。現在有時間，就對mq的一些簡單的概念做下整理吧。

rabbitmq的一些介紹，請參考裡面對一些概念和使用的講解還是非常詳細的。

什麼是訊息佇列-定義

我們來看下維基百科上面的定義：

是一種程序間通訊或同一程序的不同執行緒間的通訊方式，軟體的軟體的貯列用來處理一系列的輸入，通常是來自使用者。

訊息佇列提供了非同步的通訊協議，每乙個貯列中的紀錄包含詳細說明的資料，包含發生的時間，輸入裝置的種類，以及特定的輸入引數。

也就是說：訊息的傳送者和接收者不需要同時與訊息佇列互動。訊息會儲存在佇列中，知道接收者取回它。

下面是架構圖：

producer：訊息生產者，負責生產和傳送訊息到broker；

broker：訊息處理中心，負責訊息儲存、確認、重試等；

consumer：訊息消費中心，負責從broker中獲取訊息並處理。

訊息佇列-特性

非同步性：將耗時的同步任務通過傳送訊息的方式進行非同步處理，減少等待時間。

松耦合：不同系統、服務之間可以通過訊息佇列進行通訊，不用關心彼此的實現細節，資料格式一致。

分布式：為了防止訊息堵塞，可以對消費者集群進行橫向擴充套件，避免單點故障，同樣佇列本身也可以。

應用場景-簡單描述

根據特性，應用場景可以簡單描述為：

在處理高併發，而且不需要立即獲取結果的時候。

常用的訊息佇列有：

rabbitmq，rocketmq，activemq，kafka等。資料庫redis或者mysql也可以實現訊息佇列模式。redis實現訊息佇列模式可以參考之前的一篇介紹redis的隨筆

應用場景-非同步處理

應用場景-應用解耦

應用場景-限流削峰

應用場景-日誌處理

訊息模式介紹-簡介

1、點對點模式：req/rep

最基本的模式，生產者傳送一條訊息，消費者去除並消費資訊，給出響應後會從佇列中刪除該訊息，所以不能重**送，只能被乙個消費者消費。

2、發布/訂閱模式：pub/sub

3、推/拉模式：push/pull

也是一種比較重要的模式，無論是push端還是pull端都可以做伺服器，繫結到特定的位址等待對方訪問。

如果我們在push端繫結位址，那麼這是乙個pushserver，對應的pullclient可以鏈結到這個pushserver往外拉資料；反之，如果建立乙個pullserver，對應的pushclient就可以鏈結到pullserver並往裡面壓資料。

4、路由/**模式：router/dealer

是一種典型的中間人模式，比較適用於多對多的網路當中，雙方在互相不認識的情況下達成共識並交易。模擬於：顧客--->超時

使用turbomq的注意事項：

1、避免多執行緒處理訊息，減少非同步請求，不要開多餘的task去處理訊息

2、減少無效的重複推送，高併發下可以利用redis做一些去重處理。

下圖是市場上的一些訊息佇列mq：