姜偉鋒，美利金融融資財務團隊JAVA後端技術專家，曾從事於互聯網金融P2P、第三方支付相關交易、支付、清結算、賬務平臺系統相關架構設計、研發工作，目前從事於財務項目相關的工作。個人博客：https://my.oschina.net/u/3775437/blog
一、說在前面
分佈式是一個老生常談的話題了，大家都在做服務拆分、微服務化，那麼數據庫層不做分片，應用的整體性能也不會得到更好的提升。今天主要說的是財務平臺的數據庫架構是怎麼演變的、不同階段的架構是為了解決什麼樣的問題。
本文框架
財務平臺數據庫架構演變：
1、分片模式
2、讀寫分離模式
二、財務平臺數據庫架構演進
1分片模式
解決的是自動化代替手工，先解決歷史數據、增量數據存儲的問題。
“架構界”有一句話是“任何架構都是為業務服務，根本目的是要解決現階段的業務問題。沒有更好的架構，只有合適不合適”，我覺得說的很有道理。
財務平臺業務處理流程是：公司大數據平臺從對接財務平臺的業務系統數據庫中抽取原始業務數據後，清洗、轉換成財務口徑的業務數據，推送到財務平臺，然後經過財務平臺的賬務處理引擎進行賬務處理。
財務平臺是對接公司的多個業務線、產品線的業務系統，擔負著公司應收應付、實收實付的財務核算職責，因此數據量巨大。目前，財務平臺線上冷熱數據總量在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補償機制實保證數據的最終一致性，這也要求應用層的事務接口必須是冪等的。
2讀寫分離模式
為什麼要做讀寫分離？
財務平臺V1.0數據庫分片解決了數據存儲的問題，SQL也已經做過性能優化，目前這種架構方案是可以支撐一段時間的，但還是有以下這些風險：
隨著業務數據量的不斷增加，因為數據庫已經分片，數據庫物理表會越來越多，所以每張物理表的索引維護是一個問題。財務平臺線上的這個版本還是1.5，Sharding-JDBC2.0已經加入了“邏輯索引”這個概念，可以解決這個問題，既便是這樣可能也需要人為去維護索引。
前臺頁面查詢的條件也會隨著新的業務接入變化，因此，要根據頁面的輸入條件調整數據表的索引，索引的命中率無法100%保證。
MySQL索引機制決定了不能隨意增加索引，適度的增加索引可以提高查詢性能，索引過量會對其他操作有性能影響，因此索引限制這也是一個問題。
數據庫讀鎖和寫鎖的競爭也是一個問題，會降低數據庫的並行度。
基於MySQL讀寫分離
解決的是賬務處理的效率問題；
可以解決讀鎖和寫鎖競爭的問題，提高數據庫並行度。
讀寫分離對數據一致性的影響，從庫的數據延遲怎麼處理呢？
對必須要求有一致性的功能是無法進行讀寫分離的，可以針對一些場景不實現讀寫分離、一些場景實現讀寫分離這樣的方案解決在讀寫分離架構下數據一致性的問題；
從庫數據延遲的問題，業務優先級不高的話在延遲時間範圍內可以進行重試查詢，業務優先級較高的可藉助分佈式緩存方案解決。
架構圖如下所示：
基於MySQL、ES的讀寫分離
為什麼採用ES代替基於MySQL的讀操作呢？
ES採用倒排索引機制，理論上比基於MySQL的索引查詢速度能提升百倍以上；
對索引沒限制，可以用於多海量數據多維分析的場景，查詢條件約精確查詢效率越高，可以全文檢索；
維護索引方便，可以保證索引的命中率。
架構圖如下所示：
優化前後效果對比圖如下所示：
三、說在最後
這裡主要介紹了財務平臺的數據庫架構演變過程，項目搭建初期，為了保證項目按時交付，並結合財務平臺寫多讀少的業務場景，採用了分片這種架構方案。
財務平臺經過三個季度的平穩運營，隨著數據量不斷遞增，數據庫架構方案從基於Sharding-JDBC+MySQL的分片模式演變為現在的基於Sharding-JDBC+MySQL、ES的讀寫分離模式，足以支撐後續日益增長的數據量。原來基於MySQL方案查詢響應時間在秒級，現在基於ES方案查詢響應時間可以達到毫秒級，查詢性能提升了200倍左右。
閱讀更多 DBAplus社群 的文章
