美利財務平臺數據庫架構進階

說在前面

本文轉自「天河聊技術」微信公衆號

分佈式是一個老生常談的話題了，你們都在作服務拆分、微服務化，那麼數據庫層不作分片，應用的總體性能也不會獲得更好的提高。今天主要說的是財務平臺的數據庫架構是怎麼演變的、不一樣階段的架構是爲了解決什麼樣的問題。

 

內容概要

 

一、分片模式

二、讀寫分離模式

 

數據庫架構進階

一、分片模式

解決的是自動化代替手工，先解決歷史數據、增量數據存儲的問題。

「架構界」有一句話是「任何架構都是爲業務服務，根本目的是要解決現階段的業務問題。沒有更好的架構，只有合適不合適」，我以爲說的頗有道理。

 

財務平臺業務處理流程是：公司大數據平臺從對接財務平臺的業務系統數據庫中抽取原始業務數據後，清洗、轉換成財務口徑的業務數據，推送到財務平臺，而後通過財務平臺的帳務處理引擎進行帳務處理。

 

財務平臺是對接公司的多個業務線、產品線的業務系統，擔負着公司應收應付、實收實付的財務覈算職責，所以數據量巨大。目前，財務平臺線上冷熱數據總量在130TB左右，日熱數據量在5百W、月熱數據在5千萬左右。數據庫架構初期採用是主從模式，所以，財務平臺數據庫架構怎麼支撐這樣日益增加的數據量，是一個挑戰。

 

財務平臺V1.0爲了快速落地進而提升財務人效，業務目標很明確：

 

系統財務覈算代替人工財務覈算，節省人力成本。

 

結合財務平臺業務CPU、IO密集型的一個特色，爲了減小數據庫壓力、能支撐財務人員第一次龐大的歷史數據、後續增量數據帳務處理操做，數據庫架構採用了分片。從後期的效果來看，財務平臺能平穩的走到今天很關鍵的一步就是在架構設計上有了較大的改進。

 

目前數據庫分片的技術方案有不少，基於傳統數據庫有Server端的中間件如MyCat；基於Database Mesh思想架構的輕量級的Sharding-JDBC；也有新型的New SQL數據庫，如TiDB等。最後通過評估，財務平臺目前正在用的方案是Sharding-JDBC，它支持靈活的分片規則、讀寫分離、分佈式柔性事務等特性，基本上可有知足全部的業務場景。 

 

架構圖以下所示：

 

財務平臺是根據帳套字段來縱向分庫、按照建立時間字段橫向分表，後期要先根據事務處理、事務處理類型字段進行縱向分表以後再根據建立時間字段橫向分表，數據分片的維度更細一些，會把數據在數據庫層打的比較散，最大限度的提升數據庫的並行度，這樣才能更大限度的提高數據庫讀寫能力。

 

財務平臺V1.0解決了數據存儲的問題，數據庫已經實現了分片，因此查詢的問題只要合理地約束前端頁面查詢條件和Sharding-JDBC的分片字段完美結合，再加上把數據庫索引、SQL優化到位，基於MySQL理論上單表3千萬查詢速度是能夠知足業務需求的。

 

數據庫分片之後，在應用層就會多個數據庫進行事務操做。財務平臺採用的方案是TCC補償機制實保證數據的最終一致性，這也要求應用層的事務接口必須是冪等的。

 

二、讀寫分離模式

 

爲何要作讀寫分離？

 

財務平臺V1.0數據庫分片解決了數據存儲的問題，SQL也已經作過性能優化，目前這種架構方案是能夠支撐一段時間的，但仍是有如下這些風險：

 

• 隨着業務數據量的不斷增長，由於數據庫已經分片，數據庫物理表會愈來愈多，因此每張物理表的索引維護是一個問題。財務平臺線上的這個版本仍是1.5，Sharding-JDBC2.0已經加入了「邏輯索引」這個概念，能夠解決這個問題，既即是這樣可能也須要人爲去維護索引。

• 前臺頁面查詢的條件也會隨着新的業務接入變化，所以，要根據頁面的輸入條件調整數據

• 表的索引，索引的命中率沒法100%保證。

• MySQL索引機制決定了不能隨意增長索引，適度的增長索引能夠提升查詢性能，索引過量會對其餘操做有性能影響，所以索引限制這也是一個問題。

• 數據庫讀鎖和寫鎖的競爭也是一個問題，會下降數據庫的並行度。

 

基於Sharding-JDBC+MySQL讀寫分離

 

• 解決的是帳務處理的效率問題；

• 能夠解決讀鎖和寫鎖競爭的問題，提升數據庫並行度。

 

讀寫分離對數據一致性的影響，從庫的數據延遲怎麼處理呢？

 

• 對必需要求有一致性的功能是沒法進行讀寫分離的，能夠針對一些場景不實現讀寫分離、一些場景實現讀寫分離這樣的方案解決在讀寫分離架構下數據一致性的問題；

• 從庫數據延遲的問題，業務優先級不高的話在延遲時間範圍內能夠進行重試查詢，業務優先

• 級較高的可藉助分佈式緩存方案解決。

 

架構圖以下所示：

基於Sharding-JDBC+MySQL、ES的讀寫分離

 

爲何採用ES代替基於MySQL的讀操做呢？

 

• ES採用倒排索引機制，理論上比基於MySQL的索引查詢速度能提高百倍以上；

• 對索引沒限制，能夠用於多海量數據多維分析的場景，查詢條件約精確查詢效率越高，能夠全文檢索；

• 維護索引方便，能夠保證索引的命中率。

 

架構圖以下所示：

 

優化先後效果對比圖以下所示：

說到最後

這裏主要介紹了財務平臺的數據庫架構演變過程，項目搭建初期，爲了保證項目按時交付，並結合財務平臺寫多讀少的業務場景，採用了分片這種架構方案。

 

財務平臺通過三個季度的平穩運營，隨着數據量不斷遞增，數據庫架構方案從基於Sharding-JDBC+MySQL的分片模式演變爲如今的基於Sharding-JDBC+MySQL、ES的讀寫分離模式，足以支撐後續日益增加的數據量。原來基於MySQL方案查詢響應時間在秒級，如今基於ES方案查詢響應時間能夠達到毫秒級，查詢性能提高了200倍左右。

 

你們能夠根據本身項目的業務場景、不一樣階段採用不一樣的數據庫架構方案，以上內容僅供參考。