本次的內容是rabbitmq，寫這個專題的目的是為了更好的鞏固和自我總結，因為暫時作業中是用不到的，所以也是希望自己下次在使用時，也能夠借助文章輕松回顧，更快地著手應用，因為個人是第一次提及mq相關的內容，因此也會簡單地介紹mq的相關特點，
文章目錄
- 一、MQ的基本概念
- 1.1概述
- 1.2削峰填谷
- 1.3異步提速
- 1.4MQ的劣勢
- 二、RabbitMQ
- 2.1簡介
- 2.2基礎架構
- 2.3 五種常用作業模式
- 2.4 RabbitMQ訊息確認機制
一、MQ的基本概念
1.1概述
Message Queue（訊息佇列），是在訊息的傳輸程序中保存訊息的容器（中間件），
其程序是A系統只管將需要其他系統例如B系統處理的請求發到MQ中
B系統也只管去MQ中尋找需要自己處理的請求
這樣做的好處
1.2削峰填谷
服務器同時處理請求的數量是有限的，如果cpu超負荷，服務宕機后果嚴重，此時把請求放到佇列中等待，達到削峰的目的，波峰過后漸漸處理滯留的請求，達到提升系統穩定性的目的，
1.3異步提速
一個訂單完成下單，需要處理庫存，支付，物流，加起來需要九百多毫秒，把任務拆分完分給不同的系統處理，就可以大大減少時間，單位時間內就可以處理更多的數目，
有優點，自然也會帶來缺點，老天總是公平的
1.4MQ的劣勢
- 系統可用性降低
系統看似解耦了，但是各個系統都和MQ手拉手，MQ一旦宕機，大家都跑不動了， - 系統復雜度提高
MQ的加入大大增加了系統的復雜度，因為引入了MQ后是異步呼叫，就有順序，資料丟失等問題需要解決，
二、RabbitMQ
2.1簡介
- 基于AMQP網路協議的訊息中間件（Adcanced Message Queuing Protocol高級訊息佇列協議）
- RabbitMQ是采用Erlang語言開發的（Erlang語言是由Ericson設計，專門為高并發和分布式系統的一種語言）
2.2基礎架構
通過一張圖了解rabbitMQ的大體架構
- server內部有很多個虛擬機，
- 外部生產者（Producer）都是連接（connect）到指定虛擬機的指定交換機，
- 外部消費者（Consumer）都是連接到指定虛擬機的指定佇列中，
- 交換機（Exchange）和佇列（Queue）都有系結關系
RabbitMQ中的相關概念： - Broker : 接收和分發訊息的應用，RabbitMQ Server就是 Message Broker
我特地百度翻譯了一下Broker
- Virtual host : 出于多租戶的安全因素設計的， 當多個不同的用戶使用同一個MQ server提供服務時，可以花費出多個虛擬機，每個用戶在自己的虛擬機創建交換機等，就像mysql可以創建不同的資料庫一樣，每個庫都有自己的表，
- Connection ：消費者/提供者和broker之間建立的TCP連接
- Channel ：如果每次訪問Broker，都建立一次連接，在訊息量大的時候建立TCP Connection的開銷僵尸巨大的，效率也很低，Channel是connection內部建立的邏輯連接，多執行緒應用通常每個thread創建單獨的channel進行通訊，AMQP method 包含了 channel id 幫助客戶端和message broker識別channel，所以channel之間也是完全隔離的，channel作為輕量級連接，極大減少了作業系統建立TCP連接的開銷，
- Exchange：message到達exchange，根據分發規則，匹配查詢表中的routing key，分發到queue中去，常用的型別有direct（point-to-point），topic（publish-subscribe）和fanout（multicast）
- Queue：訊息在這里等待被取走
- Binding：exchange和queue之間的虛擬連接，bingding中可以包含routing key，Binding資訊被保存到exchange中的查詢表，
2.3 五種常用作業模式
（一）簡單模式
P:生產者C：消費者 queue：圖中紅色部分，生產者向其投遞訊息，消費者從中取出訊息
（二）Work Queues作業佇列模式
與簡單模式相似，多了一個或多個消費者，多個消費者共同消費同一個佇列中的訊息
（三）發布與訂閱模式
這里出現了交換機的概念，前面兩種模式不是沒有交換機，只是使用了默認交換機
交換機：
- 接收生產者發送的訊息
- 投遞給對應的佇列
交換機一共有三種型別：
- fanout：廣播，將訊息繳費所有系結到交換機的佇列
- Direct：定向，把訊息交給符合指定routing key的佇列
- Topic：通配符，把訊息交給符合routing pattern（路由模式）的佇列
- 注意，交換機只負責轉發，不負責存盤，如果沒有找到要發送的佇列，那么訊息會丟失
（四）路由模式
- 佇列越交換機的系結，不是任意系結，要指定一個RoutingKey（路由Key）
- 訊息發送給交換機，也必須指定訊息的RoutingKey
- 交換機不會交給每一個系結的佇列，二十根據RoutingKey判斷，只有佇列的RoutingKey和訊息的RoutingKey完全一致，才會接收到訊息
（五）通配符模式
- Topic型別與Direct相比，都是通過RoutingKey把訊息路由到不同的佇列，只不過Topic型別Exchange可以讓佇列在系結Routing key的時候使用通配符！
- RoutingKey一般是有一個或多個單詞組成，用“.”分割，
- 通配符規則：#匹配一個或多個詞，*匹配恰好一個詞
例如：
- 紅色Queue：系結的是usa.#，因此以usa.開頭的routing key 都會被匹配到
- 黃色Queue：系結的是#.news，因此凡是以.news結尾的routing key 都會被匹配到
2.4 RabbitMQ訊息確認機制
RabbitMQ在訊息傳遞的程序中，充當了代理人（Broker）的角色，那生產者（Producer）怎樣知道訊息被正確投遞了呢？
- RabbitMQ提供了監聽器（Lisener）來接收訊息投遞的狀態，
- 訊息確認有兩種狀態：Confirm和Return
- Comfirm代表生產者將訊息送到Broker時產生的狀態，后續會出現兩種情況
- ack 代表Broker已經將資料接收
- nack 代表Broker拒收訊息，
- Return代表被Broker正常接收（ack）后，但Broker沒有對應的佇列進行投遞時產生的狀態，訊息被退回給生產者
- 這兩種狀態只是生產者和Broker之間的關系，與是否消費無關
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/296532.html
標籤：其他