全網(wǎng)RabbitMQ總結，別再說你不會RabbitMQ
當初我學RabbitMQ的時候，第一時間就上GitHub找相應的教程，但是令我很失望的是沒有找到，Spring，Mybatis之類的教程很多，而RabbitMQ的教程幾乎找不到，后來想著索性自己總結一下吧，有不恰當?shù)牡胤綒g迎小伙伴指出。
這篇文章主要是對著我在GitHub上的源碼解釋的，因此本文并沒有太多的源碼。寫了挺長時間的，為了防止迷路，歡迎大家star和fork
github地址：https://github.com/erlieStar/rabbitmq-examples
前言
我們先來看一下一條消息在RabbitMQ中的流轉過程
圖示的主要流程如下
- 生產(chǎn)者發(fā)送消息的時候指定RoutingKey，然后消息被發(fā)送到Exchange
- Exchange根據(jù)一些列規(guī)則將消息路由到指定的隊列中
- 消費者從隊列中消費消息
整個流程主要就4個參與者message，exchange，queue，consumer，我們就來認識一下這4個參與者
Message
消息可以設置一些列屬性，每種屬性的作用可以參考《深入RabbitMQ》一書
Exchange
接收消息，并根據(jù)路由鍵轉發(fā)消息到所綁定的隊列，常用的屬性如下
我們最常使用的就是type屬性，下面就詳細解釋type屬性
Fanout Exchange
發(fā)送到該交換機的消息都會路由到與該交換機綁定的所有隊列上，可以用來做廣播
不處理路由鍵，只需要簡單的將隊列綁定到交換機上
Fanout交換機轉發(fā)消息是最快的
Direct Exchage
把消息路由到BindingKey和RoutingKey完全匹配的隊列中
Topic Exchange
前面說到，direct類型的交換器路由規(guī)則是完全匹配RoutingKey和BindingKey。topic和direct類似，也是將消息發(fā)送到RoutingKey和BindingKey相匹配的隊列中，只不過可以模糊匹配。
- RoutinKey為一個被“.”號分割的字符串(如com.rabbitmq.client)
- BindingKey和RoutingKey也是“.”號分割的字符串
- BindKey中可以存在兩種特殊字符串“*”和“#”，用于做模糊匹配，其中“*”用于匹配不多不少一個詞，“#”用于匹配多個單詞(包含0個，1個)
假如現(xiàn)在有2個RoutingKey為java.lang和java.util.concurrent的消息，java.lang會被路由到Consumer1和Consumer2，java.util.concurrent會被路由到Consumer2。
Headers Exchange
headers類型的交換器不依賴于路由鍵的匹配規(guī)則來路由消息，而是根據(jù)發(fā)送消息內(nèi)容中的headers屬性進行匹配。headers類型的交換器性能差，不實用，基本上不會使用。
Queue
隊列的常見屬性如下
arguments中可以設置的隊列的常見參數(shù)如下
rabbitmq-api(rabbitmq api的使用)
chapter_1: 快速開始，手寫一個RabbitMQ的生產(chǎn)者和消費者
chapter_2: 演示了各種exchange的使用
來回顧一下上面說的各種exchange機器路由規(guī)則
chapter_3: 拉取消息
消息的獲得方式有2種
- 拉取消息(get message)
- 推送消息(consume message)
那我們應該拉取消息還是推送消息?get是一個輪詢模型，而consumer是一個推送模型。get模型會導致每條消息都會產(chǎn)生與RabbitMQ同步通信的開銷，這一個請求由發(fā)送請求幀的客戶端應用程序和發(fā)送應答的RabbitMQ組成。所以推送消息，避免拉取
chapter_4: 手動ack
消息的確認方式有2種
- 自動確認(autoAck=true)
- 手動確認(autoAck=false)
消費者在消費消息的時候，可以指定autoAck參數(shù)
String basicConsume(String queue, boolean autoAck, Consumer callback)
autoAck=false: RabbitMQ會等待消費者顯示回復確認消息后才從內(nèi)存(或者磁盤)中移出消息
autoAck=true: RabbitMQ會自動把發(fā)送出去的消息置為確認，然后從內(nèi)存(或者磁盤)中刪除，而不管消費者是否真正的消費了這些消息
手動確認的方法如下，有2個參數(shù)
basicAck(long deliveryTag, boolean multiple)
deliveryTag: 用來標識信道中投遞的消息。RabbitMQ 推送消息給Consumer時，會附帶一個deliveryTag，以便Consumer可以在消息確認時告訴RabbitMQ到底是哪條消息被確認了。
RabbitMQ保證在每個信道中，每條消息的deliveryTag從1開始遞增
multiple=true: 消息id<=deliveryTag的消息，都會被確認
myltiple=false: 消息id=deliveryTag的消息，都會被確認
消息一直不確認會發(fā)生啥?
如果隊列中的消息發(fā)送到消費者后，消費者不對消息進行確認，那么消息會一直留在隊列中，直到確認才會刪除。
如果發(fā)送到A消費者的消息一直不確認，只有等到A消費者與rabbitmq的連接中斷，rabbitmq才會考慮將A消費者未確認的消息重新投遞給另一個消費者
chapter_5: 拒絕消息的兩種方式
確認消息只有一種方法
basicAck(long deliveryTag, boolean multiple)
而拒絕消息有兩種方式
- basicNack(long deliveryTag, boolean multiple, boolean requeue)
- basicReject(long deliveryTag, boolean requeue)
basicNack和basicReject的區(qū)別只有一個，basicNack支持批量拒絕
deliveryTag和multiple參數(shù)前面已經(jīng)說過。
requeue=true: 消息會被再次發(fā)送到隊列中
requeue=false: 消息會被直接丟失
chapter_6: 失敗通知
chapter_6到chapter_10主要簡述了消息發(fā)布時的權衡
我們最常用的就是失敗通知和發(fā)布者確認
當消息不能被路由到某個queue時，我們?nèi)绾潍@取到不能正確路由的消息呢?
- 在發(fā)送消息時設置mandatory為true
- 生產(chǎn)者可以通過調(diào)用channel.addReturnListener來添加ReturnListener監(jiān)聽器獲取沒有被路由到隊列中的消息
mandatory是channel.basicPublish()方法中的參數(shù)
mandatory=true: 交換器無法根據(jù)路由鍵找到一個符合條件的隊列，那么RabbitMQ會調(diào)用Basic.Return命令將消息返回給生產(chǎn)者
mandatory=false: 出現(xiàn)上述情形，則消息直接被丟棄
chapter_7: 發(fā)布者確認
當消息被發(fā)送后，消息到底有沒有到達exchange呢?默認情況下生產(chǎn)者是不知道消息有沒有到達exchange
RabbitMQ針對這個問題，提供了兩種解決方式
- 事務(后面會講到)
- 發(fā)布者確認(publisher confirm)
而發(fā)布者確認有三種編程方式
- 普通confirm模式：每發(fā)送一條消息后，調(diào)用waitForConfirms()方法，等待服務器端confirm。實際上是一種串行confirm了。
- 批量confirm模式：每發(fā)送一批消息后，調(diào)用waitForConfirms()方法，等待服務器端confirm。
- 異步confirm模式：提供一個回調(diào)方法，服務端confirm了一條或者多條消息后Client端會回調(diào)這個方法。
異步confirm模式的性能最高，因此經(jīng)常使用，我想把這個分享的細一下
- channel.addConfirmListener(newConfirmListener(){@OverridepublicvoidhandleAck(longdeliveryTag,booleanmultiple)throwsIOException{log.info("handleAck,deliveryTag:{},multiple:{}",deliveryTag,multiple);}@OverridepublicvoidhandleNack(longdeliveryTag,booleanmultiple)throwsIOException{log.info("handleNack,deliveryTag:{},multiple:{}",deliveryTag,multiple);}});
寫過異步confirm代碼的小伙伴應該對這段代碼不陌生，可以看到這里也有deliveryTag和multiple。但是我要說的是這里的deliveryTag和multiple和消息的ack沒有一點關系。
confirmListener中的ack: rabbitmq控制的，用來確認消息是否到達exchange
消息的ack: 上面說到可以自動確認，也可以手動確認，用來確認queue中的消息是否被consumer消費
chapter_8: 備用交換器
生產(chǎn)者在發(fā)送消息的時候如果不設置 mandatory 參數(shù)那么消息在未被路由到queue的情況下將會丟失，如果設置了 mandatory 參數(shù)，那么需要添加 ReturnListener 的編程邏輯，生產(chǎn)者的代碼將變得復雜。如果既不想復雜化生產(chǎn)者的編程邏輯，又不想消息丟失，那么可以使用備用交換器，這樣可以將未被路由到queue的消息存儲在RabbitMQ 中，在需要的時候去處理這些消息
chapter_9: 事務
RabbitMQ中與事務機制相關的方法有3個
消息成功被發(fā)送到RabbitMQ的exchange上，事務才能提交成功，否則便可在捕獲異常之后進行事務回滾，與此同時可以進行消息重發(fā)
因為事務會榨干RabbitMQ的性能，所以一般使用發(fā)布者確認代替事務
chapter_10: 消息持久化
消息做持久化，只需要將消息屬性的delivery-mode設置為2即可
RabbitMQ給我們封裝了這個屬性，即MessageProperties.PERSISTENT_TEXT_PLAIN，
詳細使用可以參考github的代碼
當我們想做消息的持久化時，最好同時設置隊列和消息的持久化，因為只設置隊列的持久化，重啟之后消息會丟失。只設置隊列的持久化，重啟后隊列消失，繼而消息也丟失
chapter_11: 死信隊列
DLX，全稱為Dead-Letter-Exchange，稱之為死信交換器。當一個消息在隊列中變成死信(dead message)之后，它能被重新發(fā)送到另一個交換器中，這個交換器就是DLX，綁定DLX的隊列就稱之為死信隊列。
DLX也是一個正常的交換器，和一般的交換器沒有區(qū)別，實際上就是設置某個隊列的屬性
消息變成死信一般是由于以下幾種情況
- 消息被拒絕(Basic.Reject/Basic.Nack)且不重新投遞(requeue=false)
- 消息過期
- 隊列達到最大長度
死信交換器和備用交換器的區(qū)別
備用交換器: 1.消息無法路由時轉到備用交換器 2.備用交換器是在聲明主交換器的時候定義的
死信交換器: 1.消息已經(jīng)到達隊列，但是被消費者拒絕等的消息會轉到死信交換器。2.死信交換器是在聲明隊列的時候定義的
chapter_12: 流量控制(服務質量保證)
qos即服務端限流，qos對于拉模式的消費方式無效
使用qos只要進行如下2個步驟即可
- autoAck設置為false(autoAck=true的時候不生效)
- 調(diào)用basicConsume方法前先調(diào)用basicQos方法，這個方法有3個參數(shù)
basicQos(int prefetchSize, int prefetchCount, boolean global)
為什么要使用qos?
- 提高服務穩(wěn)定性。假設消費端有一段時間不可用，導致隊列中有上萬條未處理的消息，如果開啟客戶端，
巨量的消息推送過來，可能會導致消費端變卡，也有可能直接不可用，所以服務端限流很重要
- 提高吞吐量。當隊列有多個消費者時，隊列收到的消息以輪詢的方式發(fā)送給消費者。但由于機器性能等的原因，每個消費者的消費能力不一樣，
這就會導致一些消費者處理完了消費的消息，而另一些則還堆積了一些消息，會造成整體應用吞吐量的下降
