RabbitMQ集群故障排查與恢復概述

1. 前言

Hello，大家好。通過上述幾個小節的學習，我們已經了解了要搭建 RabbitMQ 集群所需的全部組件，以及一些基本的配置屬性和配置項。

我們已經可以使用這些內容來搭建屬于我們自己的 RabbitMQ 集群了，但是，考慮到本套課程作為 RabbitMQ 的入門課程，所以，不會介紹搭建 RabbitMQ 集群的詳細步驟，感興趣的同學可以自行查閱資料。

本小節作為本套課程中 RabbitMQ 集群介紹章節的收尾部分，會給各位同學介紹一下，在 RabbitMQ 集群運行時，當我們的集群發生了故障，或者集群有突發情況發生時，我們應該如何應對，即如何解決這一問題，使我們的集群環境恢復到正常運行狀態。

本節主要內容：

• RabbitMQ 集群常見問題介紹；

• RabbitMQ 集群出現故障的原因分析；

• RabbitMQ 集群故障恢復方案介紹；

2.RabbitMQ 集群常見問題介紹

在我們搭建好 RabbitMQ 集群之后，無論我們采用哪種搭建方式，我們本身都需要知道一些集群中容易出現的問題，這樣我們在遇到集群出現問題的時候，我們才不會那么慌張。

問題一：集群宕機

集群宕機這一問題，是無論搭建什么樣的集群，都是比較容易出現的一種問題，這種問題出現的頻率高，同時，也是最容易修復的一種問題。

那么什么是集群宕機呢？

集群宕機其實指的就是我們的 RabbitMQ 集群，所在的服務器節點，由于種種原因導致我們的 RabbitMQ Server 服務非自然停止，或意外退出的一種現象。

如果我們的 RabbitMQ Server 宕機了，就表明，我們的 RabbitMQ 集群中有一個或多個 RabbitMQ Server 服務節點不能夠再繼續提供服務了，那么所有有關 RabbitMQ Server 服務的請求都要在正常運行的服務節點上進行處理，可想而知，這種情況下，RabbitMQ 服務器所承受的壓力有多大。

上述是集群宕機之后所造成的一個直接結果，還有一種間接結果也是非常致命的，那就是由于集群節點服務的宕機，用戶請求只能在可用的集群節點上進行處理，如果這個節點的服務器配置較低，那么很可能由于處理請求數量的激增，導致這個節點的服務器直接崩掉，也就是直接關機，或者服務器不再返回任何響應，這種情況也是比較嚴重的。

問題二：集群間通信延遲

集群間通信延遲也是比較容易出現的一種問題，這種問題我們從字面意思上來看，基本上可以知道個大概。

集群間通信延遲問題，指的就是，RabbitMQ 集群中的一個節點向另一個節點傳遞數據，或者從另一個節點中獲取數據時，目標節點不能及時將所需數據進行返回，導致的請求節點出現長時間等待的一種現象。

那么集群間通信延遲問題造成的直接影響就是，用戶的數據不能同步更新，導致用戶看到的數據是不準確的，這極大影響了用戶的使用體驗。

集群間通信延遲問題造成的間接影響就是，如果我們的目標節點遲遲不能返回響應數據，就會導致請求節點一直等待，那么位于請求節點上后續的用戶請求就不能得到處理，這就是請求阻塞現象。

問題三：集群數據文件丟失

集群數據文件丟失問題相對而言，出現的頻率較低，但是我們應該也要進行簡單的了解。

集群數據文件丟失問題，指的就是，位于服務器上的 RabbitMQ Server 節點突然出現的一種服務器磁盤數據丟失現象， 這種問題不出現還好，一旦出現，一般都是致命性的問題，往往恢復的時間也是最長的。

集群數據文件丟失問題的出現，會直接影響用戶無法打開我們的項目或應用，給用戶造成非常嚴重的體驗問題，同時，也會間接導致用戶關鍵數據的丟失，造成我們的項目或者應用用戶的一個流失。

以上三種問題類型，是 RabbitMQ 集群中比較常見的三種問題類型，無論出現哪種問題，我們都應該知道一個大概的解決措施，或者恢復方案，下面讓我們先來分析一下產生這三種問題的常見原因。

3 RabbitMQ 集群出現故障的原因分析

問題一：集群宕機

出現集群宕機問題的原因，我們可以從服務器所處的運行環境進行考慮，考慮幾種因素：

1. 服務器本身硬件配置較低，不足以支撐我們的集群服務環境，導致集群運行環境崩潰。

2. 一臺服務器上同時部署了超過 3 個或以上數量的項目，導致服務器內存被占滿，使我們的集群運行環境不能正常運行。

3. 由于開發人員自身技術問題，在部署集群時，導致集群節點沒有加入到我們的 RabbitMQ 集群隊列中去，導致我們在啟動集群時，這一集群節點不能被啟動。

問題二：集群間通信延遲

出現集群間通信延遲問題的原因，我們可以從程序本身，以及集群所處的位置來考慮，考慮幾種因素：

1. 我們在配置 RabbitMQ 集群時，不同節點間所設置的集群配置屬性的數值不合理，導致配置小的集群節點需要等待配置大的集群節點。

2. 我們在部署 RabbitMQ 集群時，我們所部署的地理位置區域之間的間隔過大，例如，我們在北京區域部署了一個服務節點，然后我們又在香港區域部署了一個服務節點，這樣無形之中就會加重我們集群節點間服務的響應時間。

3. 在處理用戶請求時，用戶請求沒有按照我們之前設定好的 RabbitMQ 集群分發策略來進行，導致用戶請求被分發到了非目標集群節點上，導致服務響應緩慢。

問題三：集群數據文件丟失

就請你數據文件丟失問題的原因，我們可以從運維和服務提供商來考慮，考慮集中因素：

1. 服務運維人員主動將 RabbitMQ 集群數據文件刪除，以報復公司或報復社會。

2. 我們的服務器服務提供方沒有提供集群數據備份機制，或服務提供方的機房不穩定，由于外界因素導致機房斷電，RabbitMQ 集群數據文件來不及備份而丟失。

3. 我們在配置 RabbitMQ 集群時，沒有配置集群數據文件備份策略，導致發生突發情況時，集群數據文件直接丟失。

4. RabbitMQ 集群故障恢復方案介紹

我們在了解了常見問題，以及常見問題的產生原因之后，我們還需要知道一些常見故障的恢復方案，這里為大家簡單介紹一下。

由于集群宕機所引發的集群故障，我們在恢復起來時，可以從集群節點發生宕機的先后順序考慮，如果我們的從節點先發生了宕機，接著主節點也發生了宕機，那么這種情況我們該如何恢復呢？

這種情況下，我們只需要先啟動我們的主節點，接著再啟動我們的從節點就行了，我們的集群也就恢復到正常運行狀態了。

如果我們主從節點同時發生了宕機，那又該如何恢復呢？

這種情況下，我們服務器所在的機房發生短暫停電的可能性最大，我們只需要在 30 秒內依次啟動主節點、從節點即可將集群恢復到正常的運行狀態。

如果我們的從節點發生了宕機，接著主節點也發生了宕機，但是，我們的從節點啟動不起來了，這種情況我們又該如何恢復呢？

這種情況我們需要先將主節點啟動起來，然后在主節點中通過運行一下命令來將不能夠啟動的從節點先從集群中剔除掉：

rabbitmqctl forget_cluster_node name(節點名稱)

然后我們可以啟動一個新的從節點，再將這個新的從節點加入到我們的 RabbitMQ 集群中來就可以了。

Tips:
1. 同學們在對不同集群節點的配置參數進行配置時，一定要綜合考慮集群所在服務器的環境，以及預估一下本節點所能扛得住的最高請求數量，這可以對我們設置集群配置參數提供一定的參考；
2. 如果集群發生了宕機或者其他突發問題，同學們一定不要慌張，一定要結合本小節所介紹的內容去冷靜的分析問題的原因，然后第一時間恢復集群的運行狀態。

5. 小結

本小節為同學們詳細介紹了 RabbitMQ 集群中較常見的幾種問題，介紹了常見問題對我們的 RabbitMQ 集群所造成直接影響與間接影響。接著，介紹了這幾種問題所產生的原因，詳細為同學們分析了常見的問題產生因素。最后，結合常見的業務場景，為同學們介紹了，場景集群故障的恢復方案。

通過以上幾部分內容的介紹，希望同學們對 RabbitMQ 中的集群問題有一個簡單的系統性地了解，這樣，同學們在實際工作中如果遇到了這些集群問題，可以第一時間進行修復。