美利财务平台数据库架构进阶

说在前面

本文转自“天河聊技术”微信公众号

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

 

内容概要

 

一、分片模式

二、读写分离模式

 

数据库架构进阶

一、分片模式

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

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

 

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

 

财务平台是对接公司的多个业务线、产品线的业务系统，担负着公司应收应付、实收实付的财务核算职责，所以数据量巨大。目前，财务平台线上冷热数据总量在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倍左右。

 

你们能够根据本身项目的业务场景、不一样阶段采用不一样的数据库架构方案，以上内容仅供参考。