現象：

最近一個系統用到了RabbitMQ訊息中心，這個系統又必須用於替換舊的系統，所以就有了必須執行在Windows 2003 32bit機器上面的限制。

因為需求獲取原因，所以可以說到了整合測試階段才知道這個限制，當系統跑起來的時候，發現一個致命性問題：RabbitMQ Broker(NT服務)不定期崩潰。

開啟windows事件管理器看到錯誤如下:

但是在windows 2003 64bit和windows 2008上面執行都沒有任何問題。

發現問題：

根據這個錯誤，猜測是RabbitMQ執行時呼叫某個函數出了問題，因為這個dll是存在的並沒有丟失，所以想先測試一下到底是哪種RabbitMQ使用方式導致出了問題，所以寫了傳送接收，釋出訂閱等測試程式測了一下，執行良好。

看來我寫的這些測試程式都無法觸發這個錯誤重現，於是正常使用系統，然後在Web管理介面觀察訊息吞吐量，這個時候意外發現用到的訊息佇列上面竟然駐留了好幾十萬條訊息了，怎麼可能，我們系統所有用到RabbitMQ的地方我都瞭解，同一時刻不可能達到這麼大的量，於是我開始思考為什麼。。。

我的測試程式和系統有什麼較大的區別？

對了，是通道，Shovel。

這裡 有針對通道的詳細介紹，這裡就不一一贅述了，我們採用的是動態通道(Dynamic Shovels)，通過Web管理介面或者dos命令動態建立和刪除，比較靈活。

我們系統是全國分散式部署，為了訊息可靠性，能夠容忍WAN環境，所以採用Shovel外掛來連線各個省份的訊息中心，難道是通道引起的麼？繼續思考。。。

突然想到一種類似於一顆彈珠在一個封閉空間內不停彈射出現數量爆炸式增長的的現象，難道我的通道出現了死迴圈麼？

再三檢查一下發現的確如此：

1 我們每個分散式RabbitMQbroker稱為一個省分中心；

2 每個省份中心都用自身的省編碼作為訊息路由的路由鍵；

3 建立的所有通道的確都已經設定了訊息推送的路由鍵；

4 所有省分中心都建立了各種出去和進來的通道；

5 所有帶有路由鍵的訊息都能夠正確路由到對應的省分中心；

一切看起來似乎很美好，但是忽略了一個很噁心的事實：

對於不帶路由鍵的訊息，可以通過帶有任何路由鍵的通道推送出去。

就是這個原因，因為我們開發的客戶端庫有一種模式傳送出去的訊息沒有路由鍵，導致這麼一條訊息進入這個系統之後，開始在各個省分中心之間不停“彈射”，最終爆炸式增長。

解決方法：

確保跨省分中心傳送的訊息（可能經過通道）都必須帶有路由鍵。

為什麼只有Windows2003 32bit會崩潰？

經過測試，發現Windows 200332bit在單個訊息佇列駐留的訊息量達到80w左右，就會導致RabbitMQ Broker崩潰。而windows 2008和windows 2003 64bit都可以在150W以上的訊息量的時候都還能穩定執行，至於上限是多少沒有具體測試。

至於為什麼會有這個區別，明顯跟作業系統位數相關，具體原因有待繼續研究。