與這個bug糾結了幾天，從懷疑消費者消費失敗訊息重發到生產者訊息傳送多次，均無果，問題只發生在雲上，測試環境無法重現，陷入了打log到否定問題點的死迴圈，好在重複消費不會影響正常的業務邏輯，不過再次收到重複的消費處理失敗會傳送郵件，郵箱被轟炸了幾天。。。。。。。
請教眾方大神無果，把懷疑點瞄準雲服務（這裡就不說是誰家的雲了。。），提交工單，通過工單系統進行問題陳述，再到**溝通細節，還好雲服務工單處理者還算給力，通過排查日誌發現，訊息未及時ack掉，重新回到了佇列，聽到這個結果第一時間想到的是不可能，因為rabbitmq如果訊息未及時ack掉，訊息還是會回到隊頭，將會極大的影響效率，所以從**編寫之初就考慮收到訊息直接ack掉，如果處理失敗再次重試傳送訊息讓訊息回到隊尾既不影響效率也會再次處理，並在訊息頭新增重試次數的字段防止訊息無限迴圈重試。
ok既然有思路了那咱們就在打一次日誌吧確定了問題，既然懷疑訊息ack超時回到了佇列，那我們增加乙個訊息唯一標示來保證唯一性，使用guid新增到messageid並在每一次收到訊息的時候記錄，發布到線上等待觸發，晚 7點收到大量錯誤郵件，不慌不忙的開啟資料庫檢視資料處理結果，無誤資料全部處理結束（新確定業務邏輯正確），開啟mongodb檢視日誌（因為訊息是json格式而且記錄日誌的**也是通用的，所以使用mongodb進行記錄），從郵件裡隨便找了一條messageid通過mongodb進行搜尋，果然發現3，4條！至此確定問題。
既然問題找了那麼解決方案自然只會比問題多，但是這裡還是需要分析一波，首先生產伺服器肯定是要比測試伺服器快的，處理訊息的速度自然應該更快，測試環境不會發生問題，而我使用的是docker上最新版本的rabbitmq而雲上的版本未知。所以問題可能是雲上版本過久（當然只是懷疑），首先推出的解決方案，使用rabbitmq無ack模式也就是不需要等待消費者的ack，預設已經處理。
至此本文結束，此文權當記錄之用無其他意義。
記一次線上問題排查
這次線上問題來的比較突然，影響也大，用部落格記錄下整個過程，也當作是對這次事故的一次總結歸納。day1 2018年06月21號上午10點，收到運營同事通知，http com api 訪問量劇增，日誌量達到80g 天，而且有上公升趨勢。運營同事讓我們排查，這種訪問是否正常。運營統計訪問量 收到通知後立...
記一次線上快取問題
今天上線專案時，檢視乙個軟體列表，我的介面裡是findall,可是軟體列表裡沒有type欄位沒有出現，後來檢查發現 是線下softmodel裡type欄位沒更新過來，清完線下表快取，並用gii重新生成了下softmodel，然後再次上線。再次檢視線上該軟體列表，還是沒有type欄位，估計第一次檢視的...
記一次線上OOM問題
首先是 jmap dump format b,file file.hprof 匯入mat工具 定位的問題是 standardmanager和standardsession檢視原始碼發現concurrenthashmap node就是standardmanager的session屬性 protecte...