分布式是一个老生常谈的话题了，大家都在做服务拆分、微服务化，那么数据库层不做分片，应用的整体性能也不会得到更好的提升。今天主要说的是财务平台的数据库架构是怎么演变的、不同阶段的架构是为了解决什么样的问题。

解决的是自动化代替手工，先解决历史数据、增量数据存储的问题。

“架构界”有一句话是“任何架构都是为业务服务，根本目的是要解决现阶段的业务问题。没有更好的架构，只有合适不合适”，我觉得说的很有道理。

财务平台业务处理流程是：公司大数据平台从对接财务平台的业务系统数据库中抽取原始业务数据后，清洗、转换成财务口径的业务数据，推送到财务平台，然后经过财务平台的账务处理引擎进行账务处理。

财务平台是对接公司的多个业务线、产品线的业务系统，担负着公司应收应付、实收实付的财务核算职责，因此数据量巨大。目前，财务平台线上冷热数据总量在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索引机制决定了不能随意增加索引，适度的增加索引可以提高查询性能，索引过量会对其他操作有性能影响，因此索引限制这也是一个问题。

• 数据库读锁和写锁的竞争也是一个问题，会降低数据库的并行度。

基于MySQL读写分离

• 解决的是账务处理的效率问题；

• 可以解决读锁和写锁竞争的问题，提高数据库并行度。

读写分离对数据一致性的影响，从库的数据延迟怎么处理呢？

• 对必须要求有一致性的功能是无法进行读写分离的，可以针对一些场景不实现读写分离、一些场景实现读写分离这样的方案解决在读写分离架构下数据一致性的问题；

• 从库数据延迟的问题，业务优先级不高的话在延迟时间范围内可以进行重试查询，业务优先级较高的可借助分布式缓存方案解决。

架构图如下所示：

基于MySQL、ES的读写分离

为什么采用ES代替基于MySQL的读操作呢？

• ES采用倒排索引机制，理论上比基于MySQL的索引查询速度能提升百倍以上；

• 对索引没限制，可以用于多海量数据多维分析的场景，查询条件约精确查询效率越高，可以全文检索；

• 维护索引方便，可以保证索引的命中率。

架构图如下所示：

优化前后效果对比图如下所示：

这里主要介绍了财务平台的数据库架构演变过程，项目搭建初期，为了保证项目按时交付，并结合财务平台写多读少的业务场景，采用了分片这种架构方案。

财务平台经过三个季度的平稳运营，随着数据量不断递增，数据库架构方案从基于Sharding-JDBC+MySQL的分片模式演变为现在的基于Sharding-JDBC+MySQL、ES的读写分离模式，足以支撑后续日益增长的数据量。原来基于MySQL方案查询响应时间在秒级，现在基于ES方案查询响应时间可以达到毫秒级，查询性能提升了200倍左右。

大家可以根据自己项目的业务场景、不同阶段采用不同的数据库架构方案，以上内容仅供参考。