線上發生了一次退款失敗的case，通過客訴反饋，這個問題出現的機率極低，跟了半天日誌，發現了根因：
上游重複呼叫了兩次，這兩次呼叫打在了不同的機器上；
而且先打到的機器並沒有原子性的執行完步驟一和步驟二，導致機器b處理時步驟一的邏輯處理是錯誤的，同時導致步驟二結果不符合預期；
機器a執行步驟二時，由於機器b已經執行並落庫，因資料庫唯一索引導致機器a執行失敗；
執行順序大致是這樣的
1、**增加分布式鎖 防止併發問題
2、**邏輯優化，保證冪等性，分布式鎖解決不了間隔時間較長的重複呼叫。
記一次線上問題排查
這次線上問題來的比較突然，影響也大，用部落格記錄下整個過程，也當作是對這次事故的一次總結歸納。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...