RabbitMQ之監控(3)

確定RabbitMQ能夠健康的運作還不足以讓人放松警惕。考慮這樣一種情況：小明為小張建立了一個隊列并綁定了一個交換器，之後某人由于疏忽而陰差陽錯的删除了這個隊列而無人得知，最後小張在使用這個隊列的時候就會報出“NOT FOUND”的錯誤。如果這些在測試環境中發生，那麼還可以彌補。如果在實際生産環境中，如果誤删了一個隊列，那必然會造成不可估計的影響。此時業務方如果正在使用這個隊列，正常情況下會立刻報出異常，相關人員迅可以迅速做出動作以盡可能的降低影響。試想如果是一個定時任務調用此隊列，并在深夜3點執行相應的邏輯，此時報出異常想必也會對相關人員造成不小的精神騷擾。

不止删除隊列這一個方面，還有删除了一個交換；或者修改了綁定資訊；亦或者是胡亂建立了一個隊列綁定到現有的一個交換器中，同時又沒有消費者訂閱消費此隊列，進而留下消息堆積的隐患等等都會對使用RabbitMQ服務的業務應用造成影響。是以對于RabbitMQ中繼資料的管理與監控也尤為重要。

許多應用場景是在業務邏輯代碼中建立相應的中繼資料資源（交換器、隊列以及綁定關系）并使用。對于排他的、自動删除的這類非高可靠性要求的中繼資料資源可以一定程度上忽略中繼資料變更的影響。但是對于兩個非常重要的且通過消息中間件互動的業務應用，在使用相應的中繼資料資源時最好做相應的管控，如果一方或者其它方肆意的變更所使用的中繼資料必然對另一方造成不小的影響。管控的介入自然會降低消息中間件的靈活度，但是可以增強系統的可靠性。比如通過專用的“中繼資料稽核系統”來配置相應的中繼資料資源，提供給業務方使用的使用者隻有可讀和可寫的權限，這樣進一步可以降低風險。

非管控的中繼資料可以天馬行空，業務方可以在這一時刻建立，下一時刻就删除，對其監控也無太大的意義。對于管控的中繼資料來說，監控的介入就會有意義也會有必要很多。雖然對于隻有可讀寫權限的使用者不能夠變更中繼資料資訊，也難免會被其他具有可配置權限的超級使用者篡改。RabbitMQ中在建立中繼資料資源的時候是以一種聲明的形式完成的：無則建立、有則不變，不過在對應的中繼資料存在的情況下，對其再次聲明時使用不同的屬性會報出相應的錯誤資訊。我們可以利用這一特性來監控中繼資料的變更，通過定時程式來将記錄中的中繼資料資訊重新聲明一次，檢視是否有異常報出。不過這種方法非常具有局限性，隻能增加中繼資料的資訊，而不能減少。比如有一個隊列沒有消費者且以後也不會被使用，我們對其進行了解綁操作，這樣就沒有更多的消息流入而造成消息堆積，不過這一變更由于某些局限性沒有及時将記錄變更以通知到那個定時程式，此時又重新将此隊列綁定到原交換器中。

這裡列舉一個簡單的中繼資料管控及監控的示例來應對此種情況，此系統并非最優，但可以給讀者在實際應用時提供一種解決對應問題的思路。

如圖所示，所有的業務應用都需要通過中繼資料稽核系統來申請建立（當然也可以包含查詢、修改及删除）相應的中繼資料資訊。在申請動作完成之後，由專門的人員進行審批，之後在資料庫中存儲和在RabbitMQ叢集中建立相應的中繼資料，這兩個步驟可以同時進行，且也無需為這兩個動作添加強一緻性的事務邏輯。在資料庫和RabbitMQ叢集之間會有一個中繼資料一緻性校驗程式用來檢測出中繼資料不一緻的地方，然後将不一緻的資料上送到監控管理系統。監控管理系統中可以顯示中繼資料不一緻的記錄資訊，也可以以告警的形式推送出來，然後相應的管理人員可以選擇手動或者自動的進行中繼資料修正。這裡的不一緻有可能是由于資料庫的記錄未被正确及時的更新，也有可能是RabbitMQ叢集中中繼資料造異常篡改。中繼資料修正需慎之又慎，在整個系統修正邏輯完備之前，建議優先采用人工的方式，畢竟不一緻的中繼資料僅占少數，人工修正的工作量并不太大。

RabbitMQ的中繼資料可以很順利的以表的形式記錄在資料庫中，主要的中繼資料是“queues”、“exchanges”和“bindings”，可以分别建立三張表：

Table 1：隊列資訊表，名稱為rmq_queues。列名有name、vhost、durable、auto_delete、arguments、cluster_name、description。vhost表示虛拟主機。cluster_name表示隊列所在的叢集名稱，畢竟一般一個公司所用的RabbitMQ叢集并非隻有一個。description是相應的描述資訊，相當于備注，通常可置為空。

Table 2：交換器資訊表，名稱為rmq_exchanges。列名有name、vhost、type、durable、auto_delete、internal、arguments、cluster_name、description。vhost、cluster_name和description可參考Table 1。

Table 3：綁定資訊表，名稱為rmq_bindings。列名有source、vhost、destination、destination_type、routing_key、arguments、cluster_name、description。vhost、cluster_name和description可參考Table 1。

中繼資料一緻性檢測程式可以通過/api/definitions的HTTP API接口擷取叢集的中繼資料資訊，通過解析之後與資料庫中的記錄一一比對，檢視是否有不一緻的地方。