RabbitMQ筆記

RabbitMQ筆記

• rabbitmq中的角色可以抽象爲生產者，消費者，broker，以及兩條channel。三者之間通過channel進行交互。獲取channel需要登陸授權的Connector。生產者的channel需要配置交換器標籤和路由鍵標籤，路由鍵標籤最終代替queue標籤，之後Producer不再與queue直接接觸。而consumer的channel則需要配置好接收滑動窗口的大小，以及queue的名稱，還有消息處理handler。
• RabbitMQ的queue不支持廣播消費（沒有topic概念，如需要，需要自己封裝），但是exchanger可以做到廣播消息給多個隊列。
• RabbitMQ的架構依據是AMQP，所以最好有所瞭解。
• Exchanger可以理解爲Producer的代理，它可以把消息投遞給一個或者多個隊列
• BindingKey的官方解釋“the RoutingKey to use for Binding”, 從這句話可以理解爲綁定鍵就是用來綁定的路由鍵，也就是說路有鍵可以分爲未綁定的，和綁定過的（將exchanger和queue綁定）。之後producer就是面向bindingkey發佈消息。
• topic交換器可以使得bindingkey支持模糊匹配的能力，從某種意義上看，topic類型是direct類型的增強版。
• exchanger由四種類型的direct,topic，fanout,headers。其中fanout就是全量廣播，而topic支持模糊廣播，而direct可以支持確定性廣播。實際上用的最多的應該是topic，因爲它的自定義功能最強大。
• channel實現了對tcp連接connector的複用。減少了網絡IO的開銷。它是AMQP提出的概念。
• AMQP協議是基於TCP協議之上的應用層協議，它的握手和關閉頁TCP一樣是穩定可靠保守的通訊協議，性能也相對低。（比如一樣擁有滑動窗口機制）
• AMQP協議中每次deliver都需要一個ack

#### 學習完AMQP的總結：
它是一個穩定可以靠的同學協議，它的角色是客戶端和broker服務器，它的操作對象是消息，隊列，交換器，連接，channel配置，事務，confirm機制配置。事務是同步耗性能的，confirm是異步高性能的。

• channel是非線程安全的，但是它的isopen（）方法是同步安全的，不過代價很大，它使用了syntronized關鍵字。

• 交換器可以自由組合

• 聲明隊列排他性是關鍵詞：首次創建的連接可見，關閉連接後自動刪除。

• 自動刪除的定義是，至少被消費者連接過一次，之後不再有任何client連接，就會被刪除。

• basic.consume是異步的比basic.get的吞吐量高很多。

• 如果消費者沒有ack時掛掉，消息會馬上回到重新分發隊列，如果消費者連接沒有斷開，這個消息會一直處於待確認狀態。

• basic.recover默認會重新分發消息給與之前不同的消費者處理。

• mandatory 爲true，無隊列的消息會返回給producer的returnlistener處理。

• 如果沒有隊列接受的消息，不想丟失，也不想返回，可以交給備胎交換器alternate-exchanger處理。

• 備胎交換器的優先級 > mandatory > policy（rabbitmqctl set_policy ）

• 備胎交換器丟失的信息無任何異常日誌。

• 可以給隊列所有方法設置相同的秒級過期時間TTL，過期的消息會定義被清除。也可以對單個消息設置毫秒級TTL，過期時延遲到即將投遞之前判斷是否過期拋棄（這種延遲刪除有點類似delayQueue的實現），如果兩種都設置了，則取最短的TTL爲準。

• ttl爲0則表示消息馬上投遞給消費者，無消費者則給備胎exchanger或returnlistener或policy（過期）。

• 隊列的生命也可以設置TTL，不過rabbitmq重啓後隊列過期時間重新計算。

• 死信郵箱DLX可以接受被拒絕，過期，隊滿時拋棄的消息。是重要的優化工具。（TTL+DLX）

• 可以利用TTL+DLX死信郵箱機制模擬實現延遲隊列，延遲隊列是調度器線程池的核心工具。但是死信隊列沒有優先級，所以不同TTL的消息要放到不同的隊列，又或者給隊列和消息設置優先級。

• 生產者的可靠發佈，可以通過同步事務和異步確認來實現，如果異步確認採用waitforconfirm性能會退化接近同步事務。而較爲常見的手段有批量同步confirm,和異步批量confirm.

• 如果rabbitmq服務器在接受消息時出現異常就會返回給客戶端basic.nack命令要求重發。

• 在批量模式下，出現nack是很耗性能的事，因爲它會要求這批消息重發。這個模式下批量發生的條數是由rabbitmq服務器設置的。

• 在rabbitmq當中，Qos的滑動窗口大小中的global參數的含義：false表示，對針對每個接下來創建的consumer設置窗口，true表示該針對channel設置窗口大小。

• 任何一個環境都可能會導致消息亂序，要確保有序只有一個方案，就是要求消息到處理前重排序，獲取只處理期望得到的需要的消息，類似新增自定義滑動窗口。

• Rabbitmq確保消息至少被消費一次的方法是：
  1.生產者採用confirm模式（或者事務模式）
  2.採用死信隊列和備胎交換器
  3.broker持久化
  4.consumer採用手動確認

• 目前所有MQ都無法保證消息能去重，最多隻能確保不丟失。

• 一臺服務器上的rabbitmq應用程序是支持多租戶vhost的，默認是/

• connector共享和queue的輪訓是rabbitmq的性能瓶頸之一

CAP

網絡分區是否具備容錯性決定了可用性和一致性

一個網絡分區發生後如果具有容錯算法或者同步冗餘數據算法，比自動把故障節點剔除或者同步數據，那麼網絡在剔除或同步數據期間就不可用了（並非一直可用）。但是對外的服務數據一直保持着一致性，這種就是CP原則。

如果網絡發生分區後，繼續服務即一直可用，就會出現數據不一致。那麼網絡就是AP原則。

如果網絡發生分區後直接掛掉，那麼網絡從掛掉之前網絡一直可用且數據一致，那麼就是CA。這跟單機沒什麼區別了。

• rabbit垃圾會緩存後集中回收，內存報警的閾值是40%，超過這個值就會禁止生產者加入消息，最壞的情況下垃圾回收會導致內存使用率達到80%
• 硬盤的告警閾值爲可用剩下50M