作者：京東科技 杜曉玉
前言
資料庫，交易系統中最核心依賴，資料持久化屬于最核心服務，
隨著互聯網的普及，大流量高并發的場景越來越多，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操作切換到創建流水資料的操作；
總結
以上資料庫弱依賴的技術方案更適用于資料偏流水式的交易系統，隨技術迭代和業務發展，技術方案也層出不窮并不斷迭代創新，歡迎大家跟我們研發團隊交流溝通，共同進步，
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/547857.html
標籤：其他
下一篇：高性能 Flink SQL 優化