讀《RabbitMQ 實戰》有感。
生產者確認模式： 通過設置信道模式爲 confirm ，修改生產者確認模式，只有在成功將消息發送到隊列纔會確認該消息發送成功，否則，發送失敗。在開啓 持久化的情況下，只有將消息持久化到磁盤，纔會發送確認給生產者。
可以通過在應用程序內容維護一個信道的消息msg_id 來確認某一條消息時候成功發送到 隊列中，一般不需要該操作，除非客戶要求。
集羣中的隊列：在單一節點設置中，所有關於隊列的消息都完全存儲在該節點上。但是如果在集羣中創建隊列的話，集羣只會在單個節點而不是所有節點上創建完整的隊列信息（元數據，狀態、內容）。結果是隻有隊列的所有者知道有關隊列的所有信息。所有其他非所有者節點只知道隊列的元數據和指向該隊列存在的按個節點的指針。
內存節點還是磁盤節點：如果集羣只有一個磁盤節點，當磁盤節點崩潰的時候，集羣仍然可以保持運行，但是直到該節點恢復前，你無法修改任何東西。包括：創建隊列，創建交換器，創建綁定，添加用戶，更改權限，添加和刪除集羣節點。，
這麼看，磁盤節點存儲的是集羣的配置信息，所有的配置文件內容。內存節點只保存元數據，也就是當前的信息數據。
所以，集羣應該有兩個磁盤節點，保證在一個節點不可用時，能在任何時候保存元數據變更。只有一需要所有的磁盤節點同時在線的操作是 添加和刪除集羣節點。
對於多個磁盤節點的集羣，在添加內存節點的 時候，需要告知內存節點，集羣中的所有磁盤節點。（內存節點的元數據都保存在內存中，唯一保存到磁盤的信息是 集羣中磁盤節點的地址）
聲明並使用鏡像隊列：（全部都是磁盤節點）version 2.7 之前
聲明磁盤節點爲主節點，其他節點作爲從節點加入集羣。當有消息入隊的時候，在主節點記錄主拷貝信息，在所有的從節點記錄從拷貝信息。
當把隊列聲明爲鏡像隊列之後，有新的節點加入集羣，新節點不能擁有之前的拷貝信息。從新的節點加入集羣開始，之前的節點維護之前的拷貝信息，新的節點開始維護自己的拷貝信息，此時發生了 集羣節點之間的拷貝不一致情況。
此時，開啓消費者的情況下，消費者會從所有的拷貝信息中，獲取消息完成消費。等到消費者將所有的消息消費完成，集羣中的所有節點的狀態變成一致的。
在主節點宕機的時候，集羣會主動推舉一個從拷貝時間最長的從節點 爲主節點。
在3.7 的版本看到了 rabbitMQ 集羣之間的 隊列自動同步。舒服了。
鏡像隊列新功能： 在隊列配置爲鏡像隊列，且配置自動同步時，假如 從節點沒有啓動，集羣收到了 消息，當從節點重啓之後，會主動同步消息到從節點上，保證消息的一致性。
rabbitmqctl set_policy policy2 "^" '{"ha-mode":"all","ha-sync-mode":"automatic"}'
RabbitMQ 會始終記錄以下四種類型的內部元數據：
隊列元數據----隊列名稱和屬性（是否可持久化，是否自動刪除）
交換器元數據---交換器名稱、類型、屬性（可持久化等）
綁定元數據---一張簡單的表格展示如何將消息路由到隊列
vhost元數據---爲vhost內的隊列、交換機和綁定提供命名空間和安全屬性
在單一節點上，RabbitMQ 會將所有的信息存儲到內存中，同時將那些標記持久化的隊列和交換器（以及他們的綁定）存儲到硬盤上，存儲到硬盤上可以確保隊列和交換器在重啓RabbitMQ節點後重新創建。
這麼看，內存節點的信息隊列和交換器，在重啓之後，是不能創建的。所以需要先重啓磁盤節點
隊列應該由 生產者還是消費者 聲明：
交換器和綁定：
爲應用創建合適的 vhost，避免在遷移時，發生默認名稱 衝突的問題：
A： 在合適時候，避免使用默認的名稱。
主節點 和 從節點：
隊列和節點的關係：
鏡像集羣：
關於 消費者取消通知：主備架構中的消費者取消，重新在備機建立隊列。
RabbitMQ 需要關心的重點知識，（根據書和網上的系列）
RabbitMQ 是什麼
持久化
異步
queue
交換器
發送方確認模式
管理
虛擬主機
RabbitMQ 的應用代碼，
集羣結構和搭建
新版本更新內容