作者：京東科技 杜曉玉

前言

資料庫，交易系統中最核心依賴，數據持久化屬於最核心服務。

隨著互聯網的普及，大流量高併發的場景越來越多，7*24的交易系統對高可用要求越來越高，同時在“數據為王”大環境下，交易數據最終通過資料庫進行持久化存儲，資料庫成為整個系統最終重要服務，不能出一點問題，尤其核心P0系統哪怕瞬間的DB操作異常可能造成大量異常交易，可能產生致命的問題，所以核心系統弱依賴資料庫都是必須考慮的。

資料庫弱依賴的整體思路：將最可靠鏈路再增加上備用鏈路替換，解決方案主要通過其他存儲介質+補償機制替換同步的DB操作，預期效果：資料庫出現故障期間也能保證系統運行正常不影響線上業務開展。

本期介紹下實踐過的三種解決方案：DB災備機制方案、DB高併發替換方案、財富系統弱依賴DB方案。

一、DB災備機制方案

日常引發資料庫操作出現異常的常見情況：網路鏈路異常、執行工單導致資料庫性能下降、慢SQL導致資料庫異常等，並且從發現問題到解決往往時間不短，尤其核心交易鏈路都已無法容忍短時間的異常故障，所以首先考慮增加災備機制，出現異常時間段內也要保證交易成功率，哪怕可以損失一點性能要求。DB災備機制方案是2016年接觸到並實施第一版弱依賴資料庫方案。方案主要思路：DB操作故障時間段內，通過其他存儲介質臨時存儲數據，並通過MQ非同步補償還原DB操作，達到最終數據一致性。

圖1 DB災備流程

具體改造點：

1.DB操作增加災備處理邏輯，出現異常時將數據存儲到緩存，併發送MQ，再通過消費MQ非同步還原DB數據操作；

2.數據查詢鏈路，必須支持先查緩存再查資料庫，並且減少外部查詢請求；

3.資料庫的DB操作性能非常好（毫秒級），災備處理鏈路同步操作入緩存+MQ發送，整體性能耗時變高了，需合理設置MQ發送超時時間，當時接入團隊內部MQSender組件，處理髮送失敗後非同步自動重發，提升災備處理鏈路的成功率，同時保障了MQ消息無丟失。

二、DB高併發替換方案

資料庫的連接數是寶貴且有限，凡是連接資料庫的系統，不可能無限進行機器擴容支持流量的增長，同時資料庫支持TPS也是有上限，例如Mysql5.6.x版本建議最大500~1000之間，尤其對高性能和高併發的系統來說，在高要求的性能指標下，資料庫吞吐量成為支撐大流量的瓶頸，如果通過增加資料庫伺服器，成本往往也是無法承擔。

2018年有幸參與到P0核心交易系統的高可用升級項目，目標將交易系統tps提升至2w以上，當時20台資料庫物理機（單機單實例，Mysql版本5.6.x），在高性能指標要求下，系統壓測tps峰值最高可達到1~1.5w。為達成目標，同時考慮資源成本，項目升級改造方案思路：通過緩存+MQ組合將資料庫操作完全非同步化，同時利用MQ消費批量拉取策略，批量拉取數據進行DB批量操作，減少資料庫操作次數提升效率。中間件選擇上充分利用緩存組件的高性能、高吞吐、支持連接數更大的優勢，保證了高性能同時也解決應用擴容問題。同時考慮到MQ平臺上部署其他應用topic影響發送性能，搭建單獨獨享MQ集群，保證MQ發送的性能要求，多次大促期間MQ發送耗時tp999都小於50ms。中間件達到高性能要求後，將DB操作替換成同步入緩存+發送MQ，提升交易鏈路吞吐量，壓測結果也達到tps>2w+目標。

圖2 DB高併發替換

具體改造點：

1.交易鏈路中DB操作全為insert，無update，滿足了非同步化後DB操作可進行批處理；

2.搭建單獨MQ平臺，保證了MQ發送性能，同時接入團隊內部MQSender組件，處理髮送失敗的非同步自動重發，保證整體鏈路的成功率；

3.緩存組件，本身具備高吞吐量並且可快速擴容，非同步化後交易鏈路吞吐量大幅提升。同時緩存接入R2M、JIMDB雙緩存，針對不同機房設置主從操作，例如金融機房同步主操作R2M，非同步操作JIMDB，性能最優。雙緩存機制防止單個緩存組件出現故障後可快速切換，保證整體鏈路成功率；

4.非同步化後通過MQ消費還原DB操作，通過合理設置MQ拉取策略，批量進行DB操作，減少DB操作提升效率；同時增加非同步化延遲的UMP監控，監控從交易發起到非同步入庫完整鏈路耗時，可直觀非同步化後MQ消費能力，便於動態調整；

5.減少外部系統的查詢訴求，統一以交易完成消息進行觸達扭轉，必要查詢請求全部查緩存，上游要具備查詢異常時重試機制。

三、財富系統弱依賴DB方案

財富交易系統參考以上兩版方案，並結合自身交易場景多、交易鏈路長、數據狀態多情況。基於此設計出一版以流水數據驅動交易數據扭轉的方案，大概思路：交易鏈路少變動，交易數據的DB操作不變動，增加中轉層將交易鏈路DB操作轉換為逐筆流水數據的持久化操作，再非同步消費MQ還原交易數據的DB操作，通過將新增中轉層做到弱依賴DB，達到整個交易鏈路弱依賴DB。結合系統的流量現狀，查詢流量大交易流量TPS未達上萬，當下主要目標加強交易鏈路的健壯性。

流水數據持久化的操作：並行執行DB入庫、入緩存，二者其一操作成功則直接返回成功，並非同步發送補償操作的MQ，如果DB出現故障期間緩存操作正常也可保證系統運行正常，不影響線上業務開展。例如消費場景的弱依賴DB改造，正常收到交易請求後，首先業務校驗+防重冪等>創建訂單>扣減用戶份額>更新訂單狀態，將創建訂單、更新訂單狀態的操作改造為創建兩筆流水數據的操作，交易鏈路不進行大的改造前提下，通過將流水數據持久化做到弱依賴DB，這樣交易過程中即使DB出現故障時只要緩存組件正常運行即可保障消費交易正常完成，再通過非同步消費MQ還原創建訂單、更新訂單的操作。方案落地後得到了很好的驗證，曾經歷過資料庫因執行大的變更工單導致資料庫出現性能故障，消費交易鏈路不受影響，保證業務正常運行和用戶體驗。

圖3 財富系統弱依賴DB方案

具體改造點：

1.中轉層流水數據持久化核心操作：並行執行DB的insert操作、入緩存，二者其一操作成功則直接返回成功，並非同步發送補償操作的MQ；

2.消費MQ非同步還原交易庫的DB操作時，通過數據中狀態位保證MQ消費的順序執行；

3.流水庫和緩存的雙向同步，如果流水庫或緩存出現故障時，非同步進行相互補償存儲，目前流水庫存儲全量流水數據。

4.交易鏈路主要改造兩點：一、防重冪等以流水數據為準，流水數據查詢是合併緩存和DB數據後返回；二、交易數據調用DB操作切換到創建流水數據的操作；

總結

以上資料庫弱依賴的技術方案更適用於數據偏流水式的交易系統，隨技術迭代和業務發展，技術方案也層出不窮並不斷迭代創新，歡迎大家跟我們研發團隊交流溝通，共同進步。