專案中要用到RabbitMQ，領導讓我先了解一下，在之前的公司中，用到過訊息佇列MQ，阿里的那款RocketMQ，當時公司也做了簡單的技術分享，自己也看了一些博客，自己在有道云筆記上，做了一些整理，但后來也就擱在那了，現在有時間，就對MQ的一些簡單的概念做下整理吧，
RabbitMQ的一些介紹，請參考https://www.jianshu.com/p/e55e971aebd8，里面對一些概念和使用的講解還是非常詳細的，
什么是訊息佇列-定義
我們來看下維基百科上面的定義：
是一種行程間通信或同一行程的不同執行緒間的通信方式，軟體的軟體的貯列用來處理一系列的輸入，通常是來自用戶，
訊息佇列提供了異步的通信協議，每一個貯列中的紀錄包含詳細說明的資料，包含發生的時間，輸入設備的種類，以及特定的輸入引數，
也就是說：訊息的發送者和接收者不需要同時與訊息佇列互動，訊息會保存在佇列中，知道接收者取回它，
下面是架構圖：
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：
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/42084.html
標籤：架構設計
上一篇：資料結構導論(第二章線性表）