來源：京東技術

導讀

在軟體開發的複雜世界中，資料庫死鎖往往是隱藏在資料操作深處的隱患，它們可能在任何時候無聲無息地破壞系統的穩定性。在最新的測試中，測試工程師竟然意外發現了一個潛伏已久的資料庫死鎖問題。這個發現不僅展示了細緻測試的重要性，也提醒我們即使是看似不起眼的系統異常，也可能是潛在大問題的冰山一角。在本文中，我們將深入探討這個死鎖是如何被發現的，以及我們可以從中學到的寶貴經驗。

01 

背景

在今年的敏捷團隊建設中，我透過Suite執行器實現了一鍵自動化單元測試。Juint除了Suite執行器還有哪些執行器呢？由此我的Runner探索之旅開始了！

測試生產監控發現資料庫死鎖報錯：org.springframework.dao.DeadlockLoserDataAccessException:

### Error updating database. Cause: com.mysql.cj.jdbc.exceptions.MySQLTransactionRollbackException: Deadlock found

測試是透過什麼方式發現呢？

還要從前一段時間開始說起。

A：理賠系統上線後，不能進行生產驗證，作為測試你要怎麼避免生產問題呢

B：目前對生產的驗證只能聯絡業務人員進行生產驗證

A：那我們測試這邊調研一下，看一下有什麼方法

B：好的，我去看一下有沒有適合的集團工具可以對生產異常資料進行統計

就是這樣的一個對話，讓我發現了EasyBI工具，和這個工具的緣分就開始了！

首先，給大家介紹一個這個工具，它可以做什麼呢？它可以透過連線生產資料庫或者介面開發的形式進行生產資料統計，以聚合表、透視表、柱狀圖、折線圖、雷達圖等進行圖形化配置，並將整個資料情況都彙總到統一的監控排程中心。

02 

  EasyBI工具詳細操作  

理解，首先 MCube 會依據模板快取狀態判斷是否需要網路獲取最新模板，當獲取到模板後進行模板載入，載入階段會將產物轉換為檢視樹的結構，轉換完成後將透過表示式引擎解析表示式並取得正確的值，透過事件解析引擎解析使用者自定義事件並完成事件的繫結，完成解析賦值以及事件繫結後進行檢視的渲染，最終將目標頁面展示到螢幕。

首先，我根據自己系統的業務型別，開發了幾個介面，生產資料異常的介面、生產理賠數量統計介面、生產TOP5理賠資料統計介面等。

然後，按照EasyBI工具使用文件進行了配置，詳細操作請看以下分析。

（一）資料接入

把開發的介面在EasyBI工具平臺（EasyBI (jd.com)）進行配置

（二）應用配置

建立應用，把配置好的介面資料以聚合表、柱狀圖、等進行圖形化配置，以該形式展示監控資料

（三）訂閱管理

配置好應用後，對此應用進行郵件訂閱，定時任務推送生產資料監控的結果

（四）監控資料分析

非車核心理賠資料統計介面：目前分為三類，分別是是錯誤資訊統計介面、周失敗和成功統計介面、日失敗和成功統計介面。

• 錯誤資訊統計介面

• 1.1 透過對理賠不同的錯誤資訊進行分類，統計出當天、本週、上週和上上週各個錯誤資訊的個數，透過資料對比能夠及時發現 當前系統的穩定性、理賠資料正確性、業務邏輯校驗合理性
• 1.2 理賠不同的錯誤資訊統計透過easyBI平臺明細表分類展示

• 1.3 透過理賠錯誤型別及時判斷是正常業務校驗或者是異常問題

  

• 周失敗和成功統計，日成功和失敗資料介面

• 2.1 針對團險的主流產品、個險的主流產品、理賠系統進行連續一週或者當天的理賠成功資料和錯誤資料統計，透過對比及時發現主流產品理賠業務的正確性，保證客戶理賠的時效性

• 2.2 週資料根據商品計劃在easyBI平臺以柱狀圖展示，日資料根據商品計劃在easyBI平臺以條形圖展示

  

  

開發過程中也會遇到一些問題，那是怎麼解決的呢？

問題就是剛開始設計方案時直接透過對理賠資料庫資料進行查詢返回對應的結果，發現介面會出現超時情況，因為理賠錯誤資料統計時需要根據理賠時的保單號查詢承保詳情介面判斷出是對應的商品計劃存在，這個是第三方的介面不受自己控制。

改進方案為透過定時任務把需要的資料先儲存到對應的資料庫，然後根據儲存到資料庫的資料進行校驗，以此可以解決介面超時問題。

我發現的資料庫死鎖就是透過錯誤資訊統計介面發現的，看到統計出的結果出現。

org.springframework.dao.DeadlockLoserDataAccessException:

### Error updating database. Cause: com.mysql.cj.jdbc.exceptions.MySQLTransactionRollbackException: Deadlock found這個非正常業務異常資訊

發現後和領導同步

A：哇哦！監控做的不錯

B：會繼續加油的

  

03 

 思考與總結 

  

理解，首先 MCube 會依據模板快取狀態判斷是否需要網路獲取最新模板，當獲取到模板後進行模板載入，載入階段會將產物轉換為檢視樹的結構，轉換完成後將透過表示式引擎解析表示式並取得正確的值，透過事件解析引擎解析使用者自定義事件並完成事件的繫結，完成解析賦值以及事件繫結後進行檢視的渲染，最終將目

基於檢測到的資料庫死鎖問題，我發現不能實時的接收到異常資料的統計和監控，那麼要怎麼實時地處理呢？

一場和同事的交流就開始了

B：我現在檢測到的異常資料是透過EasyBI工具定時傳送的，我怎麼可以實時發現異常資料

C：可以設定一個閾值，當異常資料超過這個閾值時，我們就判定為異常情況

B：那是不是可以把這個異常情況透過京me告警發給相關人員呢

C：這是個好方法

有了思路以後，說幹就幹

開發一個介面，透過異常資料的統計值與閾值進行比較，如果大於閾值，就傳送告警通知，收到的告警通知如下

因為有了這個告警，發現了生產異常情況；

    上游系統傳輸了不支援的賠付資訊，及時地通知到前端系統和相關業務

‍

‍