消息隊列MQ簡介

　　項目中要用到RabbitMQ，領導讓我先了解一下。在以前的公司中，用到過消息隊列MQ，阿里的那款RocketMQ，當時公司也作了簡單的技術分享，本身也看了一些博客。本身在有道雲筆記上，作了一些整理，但後來也就擱在那了。如今有時間，就對MQ的一些簡單的概念作下整理吧。

　　RabbitMQ的一些介紹，請參考https://www.jianshu.com/p/e55e971aebd8，裏面對一些概念和使用的講解仍是很是詳細的。

什麼是消息隊列-定義

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

　　是一種進程間通訊或同一進程的不一樣線程間的通訊方式，軟件的軟件的貯列用來處理一系列的輸入，一般是來自用戶。

　　消息隊列提供了異步的通訊協議，每個貯列中的紀錄包含詳細說明的數據，包含發生的時間，輸入設備的種類，以及特定的輸入參數。

　　也就是說：消息的發送者和接收者不須要同時與消息隊列交互。消息會保存在隊列中，知道接收者取回它。

下面是架構圖：

Producer：消息生產者，負責生產和發送消息到Broker；

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

Consumer：消息消費中心，負責從Broker中獲取消息並處理。

消息隊列-特性

　　異步性：將耗時的同步任務經過發送消息的方式進行異步處理，減小等待時間。

　　鬆耦合：不一樣系統、服務之間能夠經過消息隊列進行通訊，不用關心彼此的實現細節，數據格式一致。

　　分佈式：爲了防止消息堵塞，能夠對消費者集羣進行橫向擴展，避免單點故障，一樣隊列自己也能夠。

　　可靠性：將接收到的消息落盤，就算服務器重啓或者發生故障，恢復以後也能從新加載。

應用場景-簡單描述

　　根據特性，應用場景能夠簡單描述爲：

　　　　在處理高併發，並且不須要當即獲取結果的時候。

　　經常使用的消息隊列有：

　　　　RabbitMQ，RocketMQ，ActiveMQ，Kafka等。數據庫Redis或者MySQL也能夠實現消息隊列模式。Redis實現消息隊列模式能夠參考以前的一篇介紹Redis的隨筆

應用場景-異步處理　　　　

 應用場景-應用解耦

 應用場景-限流削峯

  應用場景-日誌處理

 消息模式介紹-簡介

一、點對點模式：REQ/REP

　　最基本的模式，生產者發送一條消息，消費者去除並消費信息，給出響應後會從隊列中刪除該消息，因此不能重複發送，只能被一個消費者消費。

 二、發佈/訂閱模式：Pub/Sub

　　很是常見也是很是有用的一種模式，將發佈者與訂閱者進行解耦。發佈者只負責生產數據，而不須要關心誰是訂閱者，有多少訂閱者。類比於微信公衆號。

 三、推/拉模式：Push/Pull

　　也是一種比較重要的模式，不管是Push端仍是Pull端均可以作服務器，綁定到特定的地址等待對方訪問。

　　若是咱們在Push端綁定地址，那麼這是一個PushServer，對應的PullClient能夠連接到這個PushServer往外拉數據；反之，若是創建一個PullServer，對應的PushClient就能夠連接到PullServer並往裏面壓數據。

四、路由/代理模式：Router/Dealer

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

使用TurboMQ的注意事項：

一、避免多線程處理消息，減小異步請求，不要開多餘的Task去處理消息

二、減小無效的重複推送，高併發下能夠利用Redis作一些去重處理。 

下圖是市場上的一些消息隊列MQ：