ActiveMQ問題排查
問題出現前使用activemq 5.11.1，排查問題中改用5.13.3：
- 背景
- 排查經過
- 結果
- 解決方案
- 總結
背景
公司內使用ActiveMQ(以下簡稱“MQ”）作爲消息中間件進行模塊間的消息傳遞。特別地，我使用MQ作爲實時檢索系統增量接收的消息中間件。MQ按Replicated LevelDB Store + zookeeper master/slave方式部署。
一開始上線並沒有發現什麼問題，過了大概一個月，發現線上增量無法及時更新了。通過MQ的console查看發現隊列的pending消息數保持在4000多，幾乎不會變，偶爾會上下跳動1。
由於是線上服務，想着儘快恢復線上服務，想到了重啓，然而簡單地執行以下命令重啓MQ服務，
> cd /home/work/MQHome
> ./bin/linux-x86-64/activemq stop
> ./bin/linux-x86-64/activemq start
重啓失敗，囧。。
看了下MQ的日誌，好像是3臺機器間數據同步出了問題，那刪了所有數據重啓吧
> ...
> rm -rf data # 好危險，慎用！！！
> ./bin/linux-x86-64/activemq start重啓成功，線上服務算是恢復了（不過應該是丟了數據），開始排查問題了
排查經過
這時才發現線上日誌也給刪掉了（在data目錄裏），無語。。
遇到問題首先想的是能以最快的速度解決問題。考慮到MQ是開源軟件，而且社區比較活躍，抱着試試看的態度查看了MQ的發佈記錄，確實MQ有大版本更新。於是，我們第一時間做了升級，從5.11.1升到5.13.3。不幸的是，同樣的情況在大概3周後又出現了。TT
沒辦法，線下復現吧。
在一臺線下機搭了MQ服務，首先懷疑是壓力過大把MQ壓垮了。通過console發送消息
然而以10000的壓力，壓了半小時，並沒有壓垮，而線上遠遠沒到這個壓力，故壓力過大的情況暫時排除。
進而懷疑是寫queue客戶端的問題，使用線上的客戶端代碼做壓測，壓了半小時，仍然沒有出現問題。
單機部署的情況都很穩定，有了第三個懷疑：集羣部署方式有問題。因爲線下沒有3臺物理機，故儘管有這個懷疑，也遲遲沒有做驗證。排除了以上兩種可能，只能在做這第三個懷疑的驗證了。在提供線上服務的3臺機器上，另外搭了一套MQ，與線上服務MQ僅端口不同。
繼續壓測，悲劇的是，壓測了半個小時仍然沒出問題，懷疑是壓的時間不夠，便又繼續壓了兩天，還是沒出問題。
這次是真的沒辦法了，只能線上復現了，若線上復現，保留好現場，然後分析日誌。
幸運的是，線上環境在重啓後3周復現了，重點日誌如下：
結果
將日誌相關內容在google中搜索一番後，發現
https://issues.apache.org/jira/browse/AMQ-5082
這個問題早在14年3月5日就有人提過，現在還是open狀態。（發稿時已是closed，並標記爲won’t fix)
在官網搜索一番發現，
進一步發現，
http://blog.klocwork.com/open-source/activemq-community-deprecates-leveldb-what-you-need-to-know/
官方將不再維護LevelDB部署方式，包括leveldb/zookeeper方式。對於現有的bug也不再修復。
解決方案
最終只能採取一種臨時方案，監控MQ的狀態，發現不能正常寫入MQ時，則重啓MQ。
接下來考慮採用公司內部的nfs部署master/slave集羣。
總結
整個問題追查及修復的過程發現：
1）線上環境不一致（java環境不同），不利於系統的維護；
2）出現問題時，未能保留好現場，對於這種非穩定復現的問題，保留好現場對定位問題是至關重要的；
最後，想說的是，在使用開源軟件之前還是應該多看看官方文檔，注意官方用語，“recommend”什麼，”should”怎樣
我們崇尚技術，追求新的技術，但在生成環境做類似的嘗試還是要慎重再慎重。
