一．消息確認
1. RabbitMQ提供了transaction、confirm 消息確認機制
2. RabbitMQ提供了transaction、confirm兩種消息確認機制。
transaction即事務機制，手動提交和回滾；confirm機制提供了Confirmlistener和waitForConfirms兩種方式。confirm機制效率明顯會高於transaction機制，但後者的優勢在於強一致性。如果沒有特別的要求，建議使用conrim機制。
2.1、從實驗來看，消息的確認機制只是確認publisher發送消息到broker，由broker進行應答，不能確認消息是否有
效消費。
2.2、而爲了確認消息是否被髮送給queue，應該在發送消息中啓用參數mandatory=true，使用ReturnListener接收
未被髮送成功的消息。
2.3、接下來就需要確認消息是否被有效消費。publisher端目前並沒有提供監聽事件，但提供了應答機制來保證消息被成功消費，應答方式：
basicAck：成功消費，消息從隊列中刪除
basicNack：requeue=true，消息重新進入隊列，false被刪除
basicReject：等同於basicNack
basicRecover：消息重入隊列，requeue=true，發送給新的consumer，false發送給相同的consumer
3. 消息確認例子：https://www.jianshu.com/p/2c5eebfd0e95
3．1
· 持久化
- exchange要持久化
- queue要持久化
- message要持久化
· 消息確認
- 啓動消費返回（@ReturnList註解，生產者就可以知道哪些消息沒有發出去）
- 生產者和Server（broker）之間的消息確認
- 消費者和Server（broker）之間的消息確認
二．消息消費
1. 消息隊列如何保證冪等性，避免消息重複消費
參考：https://www.jianshu.com/p/7d5a1bf94f2e
三.Rabbitmq集羣高可用
RabbitMQ是 erlang開發的，集羣 常 ，因爲erlang天 就是 分佈式語 ,但其本身並 持負載均衡
1.集羣中的基本概念:
RabbitMQ的集羣節點包括內存節點、磁盤節點。顧名思義內存節點就是將所有數據放在內存，磁盤節點將數據放在磁盤。 過，如前 所述，如果在投遞消息時，打開 消息的持久化，那麼即使是內存節點，數據還是安全的放在磁盤。
個rabbitmq集 羣中可以共享 user，vhost，queue，exchange等，所有的數據和狀態都是必須在所有節點上覆制的， 個 外是，那些 當前只屬於創建它的節點的消息隊 ，儘管它們可 且可被所有節點讀取。rabbitmq節點可以動態的加 到集羣中， 個節點它可以加 到集羣中，也可以從集羣環集羣會進 個基本的負載均衡。
集羣中有兩種節點:
A.內存節點:只保存狀態到內存( 個 外的情況是:持久的queue的持久內容將被保存到disk)
B . 磁盤節點:保存狀態到內存和磁盤。 內存節點雖然 寫 磁盤，但是它執 磁盤節點要好。集羣中，只需要 個磁盤節點來保存狀態 就 夠 如果集羣中只有內存節點，那麼 能停 它們，否則所有的狀態，消息等都會丟失。
那麼具體如何實現RabbitMQ 可 ，我們先搭建 個普通集羣模式，在這個模式基礎上再配置鏡像模式實現 可 ，Rabbit集羣前增加 個反向代 ， 產者、消費者通過反向代 訪問RabbitMQ集羣。
架構圖如下:圖 來 http://www.nsbeta.info 上述圖 是3個RabbitMQ運 在同 主機上，分別 同的服務端 。當然我們的 產實際 ，多個RabbitMQ肯定是運 在 不同的物理服務上，否則就失去 高可用的意義。
集羣模式配置
設計架構可以如下:在 個集羣 ，有4臺機 ，其中1臺使 磁盤模式，另2臺使 內存模式。2臺內存模式的節點， 疑速度 快，因此客戶端(consumer、producer)連接訪問它們。 磁盤模式的節點，由於磁盤IO相對較慢，因此僅作數據備份使 ，另外 臺作爲反向代 。
四臺服務 hostname分別爲:queue 、panyuntao1、panyuntao2、panyuntao3(ip:172.16.3.110) 配置RabbitMQ集羣 常簡單，只需要 個命令，配置步驟如下
step1:queue、panyuntao1、panyuntao2做爲RabbitMQ集羣節點，分別安裝RabbitMq-Server ，安裝後分別啓動RabbitMq- server 啓動命令 # Rabbit-Server start ，安裝過程及啓動命令參
:http://www.cnblogs.com/flat_peach/archive/2013/03/04/2943574.html
step2:在安裝好的三臺節點服務 中，分別修改/etc/hosts 件，指定queue、panyuntao1、panyuntao2的hosts，如:
172.16.3.32 queue 172.16.3.107 panyuntao1 172.16.3.108 panyuntao2
還有hostname 件也要正確，分別是queue、panyuntao1、panyuntao2，如果修改hostname建議安裝rabbitmq前修改。 請注意RabbitMQ集羣節點必須在同 個 段 ，如果是跨 域 效果就差。
step3:設置每個節點Cookie
Rabbitmq的集羣是依賴於erlang的集羣來 作的，所以必須先構建起erlang的集羣環境。Erlang的集羣中各節點是通過 個 magic cookie來實現的，這個cookie存放在 /var/lib/rabbitmq/.erlang.cookie 中， 件是400的權限。所以必須保證各節點 cookie保持 致，否則節點之間就 法通信。
-r--------. 1 rabbitmq rabbitmq 20 3 5 00:00 /var/lib/rabbitmq/.erlang.cookie 將其中 臺節點上的.erlang.cookie值複製下來保存到其他節點上。或者使 scp的 法也可，但是要注意 件的權限和屬主屬 組。
我們這 將queue中的cookie 複製到 panyuntao1、panyuntao2中，先修改下panyuntao1、panyuntao2中的.erlang.cookie權限 #chmod 777 /var/lib/rabbitmq/.erlang.cookie 將queue的/var/lib/rabbitmq/.erlang.cookie這個 件，拷 到panyuntao1、panyuntao2的同 位置(反過來亦可)，該 件是 集羣節點進 通信的驗證密鑰，所有節點必須 致。拷完後重啓下RabbitMQ。 複製好後別忘記還原.erlang.cookie的權限，否則可能會遇到錯誤
#chmod 400 /var/lib/rabbitmq/.erlang.cookie
設置好cookie後先將三個節點的rabbitmq重啓 # rabbitmqctl stop
# rabbitmq-server start
step4:停 所有節點RabbitMq服務，然後使 detached參數獨 運 ，這步很關鍵，尤其增加節點停 節點後再次啓動遇到 法啓動 都可以參照這個順序
queue# rabbitmqctl stop panyuntao1# rabbitmqctl stop panyuntao2# rabbitmqctl stop
queue# rabbitmq-server -detached panyuntao1# rabbitmq-server -detached panyuntao2# rabbitmq-server -detached
分別查看下每個節點
queue# rabbitmqctl cluster_status