消息中間件：RabbitMQ原理、集群、基本運維操作、常見故障處理
本次學習主要針對運維人員，和對rabbitmq不熟悉的開發人員。通過本次學習你將掌握rabbitmq 的基本原理、集群、基本運維操作、常見故障處理。
1、原理與概念
簡介
AMQP，即Advanced Message Queuing Protocol，高級消息隊列協議，是應用層協議的一個開放標準，為面向消息的中間件設計。消息中間件主要用于組件之間的解耦，消息的發送者無需知道消息使用者的存在，反之亦然。
AMQP的主要特征是面向消息、隊列、路由(包括點對點和發布/訂閱)、可靠性、安全。 RabbitMQ是一個開源的AMQP實現，服務器端用Erlang語言編寫，支持多種客戶端，如：Python、Ruby、.NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP等，支持AJAX。用于在分布式系統中存儲轉發消息，在易用性、擴展性、高可用性等方面表現不俗。
解決的問題
RabbitMQ就是當前主流的消息中間件之一。
- 兩個(多個)系統間需要通過定時任務來同步某些數據
- 異構系統的不同進程間相互調用、通訊的問題
Queue
Queue(隊列)是RabbitMQ的內部對象，用于存儲消息，用下圖表示。
RabbitMQ中的消息都只能存儲在Queue中，生產者(下圖中的P)生產消息并最終投遞到Queue中，消費者(下圖中的C)可以從Queue中獲取消息并消費。
多個消費者可以訂閱同一個Queue，這時Queue中的消息會被平均分攤給多個消費者進行處理，而不是每個消費者都收到所有的消息并處理。
技術術語
- Broker：簡單來說就是消息隊列服務器實體。
- producer：消息生產者，就是投遞消息的程序。
- consumer：消息消費者，就是接受消息的程序。
- vhost：虛擬主機，一個broker里可以開設多個vhost，用作權限分離，把不同的系統使用的rabbitmq區分開，共用一個消息隊列服務器，但看上去就像各自在用不用的rabbitmq服務器一樣。
- Connection:一個網絡連接，比如TCP/IP套接字連接。
- channel：消息通道，是建立在真實的TCP連接內的虛擬連接(是我們與RabbitMQ打交道的最重要的一個接口)。僅僅創建了客戶端到Broker之間的連接后，客戶端還是不能發送消息的,需要為每一個Connection創建Channel，AMQP協議規定只有通過Channel才能執行AMQP的命令。AMQP的命令都是通過信道發送出去的(我們大部分的業務操作是在Channel這個接口中完成的，包括定義Queue、定義Exchange、綁定Queue與Exchange、發布消息等。)。每條信道都會被指派一個唯一ID。在客戶端的每個連接里，可建立多個channel，每個channel代表一個會話任務,理論上無限制，減少TCP創建和銷毀的開銷，實現共用TCP的效果。之所以需要Channel，是因為TCP連接的建立和釋放都是十分昂貴的，如果一個客戶端每一個線程都需要與Broker交互，如果每一個線程都建立一個TCP連接，暫且不考慮TCP連接是否浪費，就算操作系統也無法承受每秒建立如此多的TCP連接。 注1：一個生產者或一個消費者與MQ服務器之間只有一條TCP連接 注2：RabbitMQ建議客戶端線程之間不要共用Channel，至少要保證共用Channel的線程發送消息必須是串行的，但是建議盡量共用Connection。
- Exchange：消息交換機，生產者不是直接將消息投遞到Queue中的，實際上是生產者將消息發送到Exchange(交換器，下圖中的X)，由Exchange將消息路由到一個或多個Queue中(或者丟棄)。
- Exchange Types RabbitMQ常用的Exchange Type有fanout、direct、topic、headers這四種(AMQP規范里還提到兩種Exchange Type，分別為system與自定義，這里不予以描述)，之后會分別進行介紹。
- Queue：消息隊列載體，每個消息都會被投入到一個或多個隊列。
- Binding：綁定，它的作用就是把exchange和queue按照路由規則綁定起來，這樣RabbitMQ就知道如何正確地將消息路由到指定的Queue了。
- Routing Key：路由關鍵字，生產者在將消息發送給Exchange的時候，一般會指定一個routing key，來指定這個消息的路由規則，而這個routing key需要與Exchange Type及binding key聯合使用才能最終生效。
- 在Exchange Type與binding key固定的情況下(在正常使用時一般這些內容都是固定配置好的)，我們的生產者就可以在發送消息給Exchange時，通過指定routing key來決定消息流向哪里。
- Prefetch count 前面我們講到如果有多個消費者同時訂閱同一個Queue中的消息，Queue中的消息會被平攤給多個消費者。這時如果每個消息的處理時間不同，就有可能會導致某些消費者一直在忙，而另外一些消費者很快就處理完手頭工作并一直空閑的情況。我們可以通過設置prefetchCount來限制Queue每次發送給每個消費者的消息數，比如我們設置prefetchCount=1，則Queue每次給每個消費者發送一條消息;消費者處理完這條消息后Queue會再給該消費者發送一條消息。
消息隊列的使用過程
在AMQP模型中，Exchange是接受生產者消息并將消息路由到消息隊列的關鍵組件。ExchangeType和Binding決定了消息的路由規則。所以生產者想要發送消息，首先必須要聲明一個Exchange和該Exchange對應的Binding。
在Rabbit MQ中，聲明一個Exchange需要三個參數：ExchangeName，ExchangeType和Durable。ExchangeName是該Exchange的名字，該屬性在創建Binding和生產者通過publish推送消息時需要指定。ExchangeType，指Exchange的類型，在RabbitMQ中，有三種類型的Exchange：direct ，fanout和topic，不同的Exchange會表現出不同路由行為。Durable是該Exchange的持久化屬性，這個會在消息持久化章節討論。
聲明一個Binding需要提供一個QueueName，ExchangeName和BindingKey。
下面是消息發送的過程：
- 建立連接Connection。由producer和consumer創建連接，連接到broker的物理節點上。
- 建立消息Channel。Channel是建立在Connection之上的，一個Connection可以建立多個Channel。producer連接Virtual Host 建立Channel，Consumer連接到相應的queue上建立Channel。
- 發送消息。由Producer發送消息到Broker中的Exchange中。
- 路由轉發。生產者Producer在發送消息時，都需要指定一個RoutingKey和Exchange，Exchange收到消息后可以看到消息中指定的RoutingKey，再根據當前Exchange的ExchangeType,按一定的規則將消息轉發到相應的queue中去。
- 消息接收。Consumer會監聽相應的queue，一旦queue中有可以消費的消息，queue就將消息發送給Consumer端。
- 消息確認。當Consumer完成某一條消息的處理之后，需要發送一條ACK消息給對應的Queue。Queue收到ACK信息后，才會認為消息處理成功，并將消息從Queue中移除;如果在對應的Channel斷開后，Queue沒有收到這條消息的ACK信息，該消息將被發送給另外的Channel。至此一個消息的發送接收流程走完了。消息的確認機制提高了通信的可靠性。
exchange 與 Queue 的路由機制
exchange 將消息發送到哪一個queue是由exchange type 和bing 規則決定的，目前常用的有3種exchange，Direct exchange, Fanout exchange, Topic exchange 。Direct exchange 直接轉發路由，其實現原理是通過消息中的routkey，與queue 中的routkey 進行比對，若二者匹配，則將消息發送到這個消息隊列。通常使用這個。
以上圖的配置為例，我們以routingKey=”error”發送消息到Exchange，則消息會路由到Queue1(amqp.gen-S9b…，這是由RabbitMQ自動生成的Queue名稱)和Queue2(amqp.gen-Agl…);如果我們以routingKey=”info”或routingKey=”warning”來發送消息，則消息只會路由到Queue2。如果我們以其他routingKey發送消息，則消息不會路由到這兩個Queue中。
Fanout exchange 復制分發路由，該路由不需要routkey，當exchange收到消息后，將消息復制多份轉發給與自己綁定的消息隊列。
上圖中，生產者(P)發送到Exchange(X)的所有消息都會路由到圖中的兩個Queue，并最終被兩個消費者(C1與C2)消費。topic exchange 通配路由，是direct exchange的通配符模式，消息中的routkey可以寫成通配的模式，exchange支持“#”和“*” 的通配。收到消息后，將消息轉發給所有符合匹配表達式的queue。
以上圖中的配置為例，routingKey=”quick.orange.rabbit”的消息會同時路由到Q1與Q2，routingKey=”lazy.orange.fox”的消息會路由到Q1，routingKey=”lazy.brown.fox”的消息會路由到Q2，routingKey=”lazy.pink.rabbit”的消息會路由到Q2(只會投遞給Q2一次，雖然這個routingKey與Q2的兩個bindingKey都匹配);routingKey=”quick.brown.fox”、routingKey=”orange”、routingKey=”quick.orange.male.rabbit”的消息將會被丟棄，因為它們沒有匹配任何bindingKey。
需要注意的一點只有queue具有 保持消息的功能，exchange不能保存消息。
headers headers類型的Exchange不依賴于routing key與binding key的匹配規則來路由消息，而是根據發送的消息內容中的headers屬性進行匹配。 在綁定Queue與Exchange時指定一組鍵值對;當消息發送到Exchange時，RabbitMQ會取到該消息的headers(也是一個鍵值對的形式)，對比其中的鍵值對是否完全匹配Queue與Exchange綁定時指定的鍵值對;如果完全匹配則消息會路由到該Queue，否則不會路由到該Queue。 該類型的Exchange沒有用到過(不過也應該很有用武之地)，所以不做介紹。
durability 持久化與非持久化隊列
如何識別? 如上圖，在Features字段里有一個D，就是持久化隊列，英文durable(持久的)。
持久化隊列和非持久化隊列的區別是什么? 持久化隊列會被保存在磁盤中，固定并持久的存儲，當Rabbit服務重啟后，該隊列會保持原來的狀態在RabbitMQ中被管理，而非持久化隊列不會被保存在磁盤中，Rabbit服務重啟后隊列就會消失。
如何選擇? 如果需要隊列的完整性，數據在隊列中的保存是必須不允許丟失的，那么可以使用持久化。而當需要獲取的信息是實時的，或者是隨機的信息，不需要信息的精確性或完整性，但是追求獲取性能，可以選擇非持久化隊列。
2、分布式集群架構和高可用性
設計集群的目的：
- 允許消費者和生產者在RabbitMQ節點崩潰的情況下繼續運行
- 通過增加更多的節點來擴展消息通信的吞吐量
集群配置方式：
RabbitMQ可以通過三種方法來部署分布式集群系統，分別是：cluster,federation,shovel
- cluster：
不支持跨網段，用于同一個網段內的局域網
可以隨意的動態增加或者減少
節點之間需要運行相同版本的RabbitMQ和Erlang。
- federation:應用于廣域網，允許單臺服務器上的交換機或隊列接收發布到另一臺服務器上交換機或隊列的消息，可以是單獨機器或集群。federation隊列類似于單向點對點連接，消息會在聯盟隊列之間轉發任意次，直到被消費者接受。通常使用federation來連接internet上的中間服務器，用作訂閱分發消息或工作隊列。
- shovel:連接方式與federation的連接方式類似，但它工作在更低層次。可以應用于廣域網。
RabbitMQ cluster 集群同步原理
上面圖中采用三個節點組成了一個RabbitMQ的集群，Exchange A的元數據信息在所有節點上是一致的，而Queue(存放消息的隊列)的完整數據則只會存在于它所創建的那個節點上。，其他節點只知道這個queue的metadata信息和一個指向queue的owner node的指針。RabbitMQ集群元數據的同步。
RabbitMQ集群會始終同步四種類型的內部元數據(類似索引)：
- 隊列元數據：隊列名稱和它的屬性；
- 交換器元數據：交換器名稱、類型和屬性；
- 綁定元數據：一張簡單的表格展示了如何將消息路由到隊列；
- vhost元數據：為vhost內的隊列、交換器和綁定提供命名空間和安全屬性; 因此，當用戶訪問其中任何一個RabbitMQ節點時，通過rabbitmqctl查詢到的queue/user/exchange/vhost等信息都是相同的。
為何RabbitMQ集群僅采用元數據同步的方式
一，存儲空間，如果每個集群節點都擁有所有Queue的完全數據拷貝，那么每個節點的存儲空間會非常大，集群的消息積壓能力會非常弱(無法通過集群節點的擴容提高消息積壓能力); 二，性能，消息的發布者需要將消息復制到每一個集群節點，對于持久化消息，網絡和磁盤同步復制的開銷都會明顯增加。
RabbitMQ cluster 集群的兩種模式
- 普通模式：默認的集群模式。
- 鏡像模式：把需要的隊列做成鏡像隊列，存在于多個節點，屬于RabbitMQ的HA方案。
普通模式：當消息進入A節點的Queue中后，consumer從B節點拉取時，RabbitMQ會臨時在A、B間進行消息傳輸，把A中的消息實體取出并經過B發送給consumer，所以consumer應平均連接每一個節點，從中取消息。該模式存在一個問題就是當A節點故障后，B節點無法取到A節點中還未消費的消息實體。如果做了隊列持久化或消息持久化，那么得等A節點恢復，然后才可被消費，并且在A節點恢復之前其它節點不能再創建A節點已經創建過的持久隊列;如果沒有持久化的話，消息就會失丟。這種模式更適合非持久化隊列，只有該隊列是非持久的，客戶端才能重新連接到集群里的其他節點，并重新創建隊列。假如該隊列是持久化的，那么唯一辦法是將故障節點恢復起來。為什么RabbitMQ不將隊列復制到集群里每個節點呢?這與它的集群的設計本意相沖突，集群的設計目的就是增加更多節點時，能線性的增加性能(CPU、內存)和容量(內存、磁盤)。當然RabbitMQ新版本集群也支持隊列復制(有個選項可以配置)。比如在有五個節點的集群里，可以指定某個隊列的內容在2個節點上進行存儲，從而在性能與高可用性之間取得一個平衡(應該就是指鏡像模式)。
鏡像模式：其實質和普通模式不同之處在于，消息實體會主動在鏡像節點間同步，而不是在consumer取數據時臨時拉取。該模式帶來的副作用也很明顯，除了降低系統性能外，如果鏡像隊列數量過多，加之大量的消息進入，集群內部的網絡帶寬將會被這種同步通訊大大消耗掉。所以在對可靠性要求較高的場合中適用。
節點類型
RAM node:內存節點將所有的隊列、交換機、綁定、用戶、權限和vhost的元數據定義存儲在內存中，好處是可以使得像交換機和隊列聲明等操作更加的快速。
Disk node:將元數據存儲在磁盤中，單節點系統只允許磁盤類型的節點，防止重啟RabbitMQ的時候，丟失系統的配置信息。
如果是內存結點這里就顯示為RAM注意：
- RabbitMQ要求在集群中至少有一個磁盤節點，所有其他節點可以是內存節點，當節點加入或者離開集群時，必須要將該變更通知到至少一個磁盤節點。
- 如果集群中唯一的一個磁盤節點崩潰的話，集群仍然可以保持運行，但是無法進行其他操作(包括創建隊列、交換器、綁定，添加用戶、更改權限、添加和刪除集群結點)，直到節點恢復。
- 解決方案：設置兩個磁盤節點，至少有一個是可用的，可以保存元數據的更改。
Erlang Cookie
Erlang Cookie是保證不同節點可以相互通信的密鑰，要保證集群中的不同節點相互通信必須共享相同的Erlang Cookie。具體的目錄存放在/var/lib/rabbitmq/.erlang.cookie。
3、基本運維操作
rabbitmq集群必要條件
綁定實體ip，即ifconfig所能查詢到的綁定到網卡上的ip,以下是綁定方法
- #編輯配置路徑 /etc/rabbitmq/rabbitmq-env.conf
- NODE_IP_ADDRESS=172.16.136.133
- 復制代碼
配置域名映射到實體ip
- #配置文件1所在路徑 /etc/rabbitmq/rabbitmq.config (如果是集群，每臺機器都需要修改這個綁定本機實體ip)
- #其中rabbit@master是創建集群時所配置的參數，@后面的參數為主機名，示例中為master
- [
- {rabbit, [
- {cluster_nodes, {['rabbit@master'], disc}},
- {cluster_partition_handling, ignore},
- {default_user, <<"guest">>},
- {default_pass, <<"guest">>},
- {tcp_listen_options, [binary,
- {packet, raw},
- {reuseaddr, true},
- {backlog, 128},
- {nodelay, true},
- {exit_on_close, false},
- {keepalive, true}]}
- ]},
- {kernel, [
- {inet_dist_listen_max, 44001},
- {inet_dist_listen_min, 44001}
- ]}
- ].
- 復制代碼
- #配置文件2 所在路徑 /etc/hosts (如果是集群，每臺機器都需要修改這個綁定本機實體ip，而且hosts文件的映射不得重復，如果重復linux系統為以最下面一條記錄為準)
- 172.16.136.133 master
- 172.16.136.134 venus
- 172.16.136.135 venus2
啟動停止
停止
- #機器A
- service rabbitmq-server stop
- epmd -kill
- #機器B
- service rabbitmq-server stop
- epmd -kill
- #機器C
- service rabbitmq-server stop
- epmd -kill
啟動
方式1
- #機器A
- service rabbitmq-server start
- #機器B
- service rabbitmq-server start
- #機器C
- service rabbitmq-server start
方式2
- rabbitmq-server -detached
集群重啟順序
集群重啟的順序是固定的，并且是相反的。 如下所述：
啟動順序：磁盤節點 => 內存節點 關閉順序：內存節點 => 磁盤節點 最后關閉必須是磁盤節點，不然可能回造成集群啟動失敗、數據丟失等異常情況。
重建集群
注1：此處的mq集群重建是比較快速和有效的方法，面向的是初次安裝或者可以接受mq中所存有的數據丟失的情況下，必須先有mq的.json后綴的配置文件或者有把握寫入集群中exchange、queue等配置。
按順序停止所有機器中的rabbitmq
- #機器A
- service rabbitmq-server stop
- epmd -kill
- #機器B
- service rabbitmq-server stop
- epmd -kill
- #機器C
- service rabbitmq-server stop
- epmd -kill
移除rabbitmq配置記錄與存儲文件
- #位于 /var/lib/rabbitmq/mensia
- mv /var/lib/rabbitmq/mensia /var/lib/rabbitmq/mensia.bak
按順序啟動所有機器中的rabbitmq
- #機器C
- service rabbitmq-server start
- #機器B
- service rabbitmq-server start
- #機器A
- service rabbitmq-server start
停止被加入集群節點app
- 比如A、B、C三臺機器，將B和C加入到A中去，需要執行以下命令
- #機器B
- rabbitmqctl stop_app
- #機器C
- rabbitmqctl stop_app
建立集群
- 注意此處master為唯一沒有執行rabbitmqctl stop_app的機器
- #機器B
- rabbitmqctl join_cluster rabbit@master
- #機器C
- rabbitmqctl join_cluster rabbit@master
啟動集群
- #機器B
- rabbitmqctl start_app
- #機器C
- rabbitmqctl start_app
- 復制代碼
檢查集群狀態
在任意一臺機器上執行rabbitmqctl cluster_status命令即可檢查，輸出包含集群中的節點與運行中的節點，兼以主機名標志
添加集群配置
創建用戶
例子中創建了兩個用戶 添加用戶add_user,設置角色set_user_tags,添加rabbitmq虛擬主機add_vhost，設置訪問權限set_permissions,以下是詳細用法
- 例子中創建了兩個用戶 添加用戶add_user,設置角色set_user_tags,添加rabbitmq虛擬主機add_vhost，設置訪問權限set_permissions,以下是詳細用法
- # 創建第一個用戶
- /usr/sbin/rabbitmqctl add_user 用戶名 密碼
- /usr/sbin/rabbitmqctl set_user_tags 用戶名 administrator
- /usr/sbin/rabbitmqctl set_permissions -p / 用戶名 ".*" ".*" ".*"
- # 創建第二個用戶
- /usr/sbin/rabbitmqctl add_user 用戶名2 密碼
- /usr/sbin/rabbitmqctl set_user_tags 用戶名2 management
- /usr/sbin/rabbitmqctl add_vhost sip_ext
- /usr/sbin/rabbitmqctl set_permissions -p sip_ext 用戶名2 '.*' '.*' '.*'
- 復制代碼
- 備注：RabbitMQ 虛擬主機，RabbitMQ 通過虛擬主機（vhost）來分發消息。擁有自己獨立的權限控制，不同的vhost之間是隔離的，單獨的。
- 權限控制的基本單位：vhost。
- 用戶只能訪問與之綁定的vhost。
- vhost是AMQP中唯一無法通過協議來創建的基元。只能通過rabbitmqctl工具來創建。
打開15672網頁管理端，訪問mq
/usr/sbin/rabbitmq-plugins enable rabbitmq_management 備注：如果發現命令執行完畢沒有打開此服務，15672端口沒有監聽，則是由于沒有重啟mq導致的
在底部導入.json后綴的配置文件即可
http://localhost:4000/first-blog/rabbitmq.jpg
如果覆蓋了用戶需要使用以下命令修改mq用戶密碼 /usr/sbin/rabbitmqctl change_password 用戶名 密碼
修改節點類型
- rabbitmqctl stop_app
- rabbitmqctl change_cluster_node_type dist
- rabbitmqctl change_cluster_node_type ram
- rabbitmqctl start_app
常用命令
4、常見故障
集群狀態異常
- rabbitmqctl cluster_status檢查集群健康狀態，不正常節點重新加入集群
- 分析是否節點掛掉，手動啟動節點。
- 保證網絡連通正常
- 隊列阻塞、數據堆積
- 保證網絡連通正常
- 保證消費者正常消費，消費速度大于生產速度
- 保證服務器TCP連接限制合理
腦裂
按正確順序重啟集群
保證網絡連通正常
保證磁盤空間、cpu、內存足夠
