光大银行分布式实战：缴费平台的数据库架构转型
本文由 dbaplus 社群授权转载。
我今天分享的主题是《高并发场景下，光大银行分布式数据库的架构转型实战》。
光大银行也是很有魄力的，拿出了一个重要的业务系统进行一次试点，做了一次这种分布式架构转型的项目。我有过十余年 DBA 相关的经验，不过之前接触比较多的主要还是传统的商用型数据库，所以能作为这次项目的推进人，也是我个人在这种新的架构下的一次学习的过程。
一、光大云缴费平台的基本情况
先给大家介绍一下今天分享的这个平台情况，对于一些业务的数据概况，可以见下图：
这个系统上线当初，是和其它的业务系统放在一起的。在 2015 年和 2018 年，考虑到业务和成本等多方面的因素，经历过两次业务剥离，最终在 18 年成了一个单独的平台。
里面涉及的缴费种类包含 20 大类，其中有 8000 余个缴费的项目，接近 500 个缴费渠道，目前覆盖国内 300+ 城市。平时大家生活中使用比较多的像水费、电费、生活费的缴纳，可能都是通过这个平台来完成的。目前，它已经被打造成为行内 TPS 最高的业务系统：
上图的这些数据，可以看出从 18 年 5 月开始，交费平台的各项数据有大幅度的增长，有的甚至是翻倍的增长。这些指标可以作为衡量一个业务系统是否有健康良好发展趋势的依据，但是转到后台，最终都代表着给数据库的压力是一个什么样的变化。
二、传统 IOE 架构的基本优化及面临的挑战
目前数据库传统的 IOE 架构是这样的：
包括云缴费系统，它用的也是这种传统的 IOE 架构，在部署模式上是采用的双中心 RAC 2+2 的冷备部署：
- 数据一致性是通过存储复制技术来保证的：这个相对来讲，光大用的时间也比较长，而且也证明了这种数据一致性保护机制是比较可靠的。
- 高可用是通过 RAC 自身特性以及一些第三方软件来提供的：不得不说，Oracle 还是有它的独到之处的，不然也不会在各个领域都能有比较高的占有率。
- 产品及架构设计是比较成熟的，运行稳定性比较高：之前，云缴费平台在这上面运行了十几年，基本上没有出过什么问题。所以这种传统的 IOE 架构确实是有它自身的优势。
在这种传统的 IOE 架构下，我们通常会做到一些优化，大致如下：
- 索引、统计信息优化 ： 目的是让它走最好、最稳定的执行计划。
- 表分区改造 ： 通过 hash、range，或是两层分区，打散 IO 消耗。
- 拆分存储端口 ： data 及 redo 端口隔离，避免端口混用时的压力影响导致提交慢。
- 硬件迭代 ： 性能、容量提升。
其实做了这么多的优化，包括还有很多其它的优化，主要目的都是为了减少 IO 请求，通过物理设备的性能提升来保障业务能有一个稳定、快速的交易响应时间。
但是，这些可能都是只对读 IO 有作用的，也就是通过尽量减少它的物理读及 buffer 读，来提升业务 TPS，并降低 ART。但是对于写来说，主要是由业务需求决定的，所以从数据库层面，至少从这种传统的架构层面是优化不掉的，因为这个是它业务传导过来的一个最基本的写的指标。
所以我们总结了一下，在传统的架构下，会面临这样的一些挑战：
- 处理能力受存储性能、热点资源制约 ： 高业务压力下，集中式存储资源性能受限，热点资源、空间分配等冲突严重。因为这种高并发的业务，在压力下，集中式存储，可以说是一个单点吧，它的资源性能是受到一定限制的。像 IOE 用到了 Oracle 的 RAC，倒也不是不能扩展，主要是它扩展不方便，而且扩展来扩展去就是加机器，CPU、内容都得到扩展了，但实际下面对的还是一个存储。所以可能最终 IO 会成为一个热点，一个压力的瓶颈。
- 部署集中导致风险集中，变更维护窗口压缩 ： 一旦出现软件产品缺陷、硬件损坏等故障时，所有的交易都会受影响，或者是变更维护操作，如果说需要停机的话，需要整个停下来才能变更（比如说打个补丁，或者是有些不能动态修改的参数之类的），都会影响系统全部交易。
- 跨数据库中心多活部署 ： 对于传统数据库来说，这种部署模式也非常困难。可能只有通过分布式的引入，才能提升多活部署的可能、提升可用性、加快切换速度，突破特性软硬件的成本和性能限制。
- 数据库产品多样化 ： 之前去“IOE”这个词也说了挺久了，毕竟还是有很多形势上的变化，所以在商业化的产品上，可能会存在一些供应链的风险。那么通过多样化的选择，可能会减少这方面的风险，同时也给我们更多部署上的选择。
三、光大的分布式数据库技术调研及思考
所以光大银行对分布式数据库的技术做了一些相关调研。
1、分布式数据库核心要点
对于数据库来讲，其实它的核心其实就是 SQL 解析、事务控制和数据存储与访问。像数据复制、备份恢复、可用性切换、数据迁移、操作调度、开发接口、权限管理、对象管理、监控报警等等，这些都是它整个的一个生态。这些工具有没有、高不高效，就决定了运维的工作能不能更好的开展。
所以，分布式数据库其实就是将传统数据库的各技术组件通过松耦合的方式部署，通过网络之间，会有一个相互的协同工作，达到分散压力，提升总体处理能力的目的。也就是把我原来的瓶颈打散了。
但是被打散之后，各个组件之间可能网络通讯成本就增加了，所以在提升总体交易吞吐量的同时，平均的响应时间也就是 ART 可能就会增加。拿云缴费这个系统来说，我们测试的时候发现原来二十几毫秒的交易，到分布式上可能就会多个十几毫秒，或者再长一点的时间，主要整体是受到一个链路的影响。所以分布式并不能减少交易响应时间，但可以通过它的扩展性，带来交易响应时间的稳定。
那为什么我们的测试发现在分布式上交易响应时间变长了呢？主要是因为原来的数据库还没达到瓶颈。等到原来这种传统架构的数据库达到一个性能瓶颈，出现性能拐点，那时候一定会出现一个大幅度的性能抖动或者滑坡。但是在分布式架构下，我们就可以通过它横向的扩展能力，让平均响应时间基本维持在恒定的一条线上。
目前，分布式部署技术很多企业都在用，但切入点是不一样的，而且也形成了多种技术路线，并且这几种路线，从我们的调研来看，也都在不断地演进。
2、常见分布式数据库的技术路线
我们的分布式数据库技术调研发现，基本上可以分为三类：
1）应用层分布式架构
主要是通过应用架构的设计，将业务数据分散到多个数据库存储。
这个其实也算是一种单元化吧，所以这层主要的核心是在于对进来的交易做一次解析，然后在交易通过应用层之后，解析完成了，它知道自己该去哪个数据库，去访问哪些数据。
2）NewSQL 分布式数据库
数据以物理分片的方式，把数据打散，分散到若干个存储节点。它是在存储层实现分布式的数据扫描和过滤。
3）数据库访问代理中间件
最早像 tomcat，也算是一个分布式中间件。这种通常都是选择恰当的分片键，通过分片键来将数据打散，然后在应用访问代理的时候，将 SQL 按照它的分片规则做一次解析，解析完成后，来实现对各个分片进行单独访问。也就是说，相当于是做了个 SQL 的拆分，由它路由到我指定的数据库上，访问指定的数据。
这是目前常见的几种分布式数据库的技术路线。
3、总结
接下来我们总结和整合一下：
第一个是分布式应用架构层面。目前在分布式数据库应用架构的路线上，就是做的分库分表，一般都是产品 / 厂商自建的。因为这种一般都比其它的与应用的业务特点，结合的是更加紧密的。对于单系统来说，它单独地进行了一些分析，对业务进行了一些拆分，效果是比较突出的，但这种模式不容易推广，因为一旦做一个系统，就需要对系统所有的交易、数据库的设计、表之类的重新梳理一次，比较费时间。不过效果确实很明显，目前这么做的系统也不少。
第二个是分布式代理中间件。主要是通过分布式代理中间件，在一定程度上实现了自动化的分库分表。实际上就是按照分片键的规则将数据拆分了，由它来进行分库分表的操作。所以这个性能还是跟应用设计有很大关系的，如果大表找不到合适的分片键的话，用这种数据库可能就达不到预期的效果。所以这类我们觉得是可以作为分布式应用架构的一种比较好的补充。
第三类就是 NewSQL 分布式。这类的性能扩展对应用相对透明，但是这些产品出来的时间相对来说都不是很长，还在演进中，开发接口等方面可能就存在一些限制，并没有前两种分布式的架构那么灵活。
四、光大自研的分布式数据库 EverDB
光大结合调研结果，采取了两个技术路线：一个是 NewSQL 的引入，一个是想要自研一个分布式数据库，也就是 EverDB。
1、EverDB 分布式数据库分层设计
EverDB 有三个主要的组件：
- EDB-grid ： 数据库访问代理组件，具有 SQL 路由、数据分片、故障转移等功能并对应用实现协议透明。（所以一个 SQL 进来，通过这层之后，解析完成就会告诉你你的数据在下面的某个 MySQL 集群上；同时分片完成之后，你也不需要关心数据是存在哪个 MySQL 库、哪个实例里，只要过了这层，就会自动地路由过去）。
- EDB-bridge ： 数据库复制和校验组件，负责逃离数据库异地灾备的数据库同步和同步数据校验。（从上图也可以看出，它是通过 bridge 复制了一个逃离数据库的，因为毕竟像这种新的技术引用，是伴随着一定的风险的，尤其是缴费这种系统，也是比较重要。所以当时的考虑是，通过 bridge 复制出来的数据库，当核心组件，也就是 grid 出现问题的时候，我可以通过应用的配置调整，让它跨过中间的所有节点，直连逃离数据库，在一定程度上快速恢复业务。这个组件主要就是承担这个作用）。
- EDB-control ： 分布式数据库管理平台，对集群中各个功能节点及数据节点进行监管。有点类似 Oracle 的 Grid control。
然后数据库实际上用的就是 MySQL 集群。数据节点采用的就是 MySQL 数据库，对部署模式没有什么限制，支持多种部署模式。
2、EverDB 分布式数据库主要功能特性
1）数据分片
- 目前支持 Hash、Mod、Range、List 等分片规则，分片功能对应用透明，应用访问数据不需要额外加什么条件。
- 分片数量需提前规划，目前不支持在线调整。（也就是说如果我一开始将数据分了 32 个片，然后底下部署了比如说 8 个 MySQL 集群，这样的话，实际上每个 MySQL 集群里是有 4 片数据的。这时如果我想要重新做分片的话，这些数据是需要重新导一遍，才能改分片数量的。所以分片数量初期的规划就比较重要，而且和后续业务的增长趋势的预估以及我相关节点的扩容计划是有关系的。因为像前面提到的 32 个分片，假设我后端的数据库扩展到 32 个 MySQL 集群的时候，那实际上每个集群里只有 1 片数据了，这个时候再想扩就扩不了了，只能是重新加分片，那就会涉及到数据迁移）。
2）数据存储
- MySQL 数据源支持主从半同步、MGR 等多种部署方式，其中主从半同步方式至少每个机房可存在一个强一致节点，从而保证跨机房切换 RPO 为 0。（不然的话，如果只是速度快，将近地 / 同机房的数据同步完了，跨机房的没有管，一旦发生宕机、网络故障时，切换过去就有可能是旧数据了。所以这块儿可能也算是网络上增加成本开销的原因，因为毕竟是要等一个跨机房的同步。相对而言，金融行业对数据一致性的要求是比较高的，所以是不允许出现数据丢失的情况）。
3）横向扩展
- 计算节点 EDB-grid 支持横向动态扩展，扩展过程对集群无任何影响，是比较透明的。也就是说，grid 直接动态增加就可以了，通过前端的 F5 配置，应用配到 F5 那层之后，F5 会自动相应的转发到新的节点上来。
- 数据节点分为物理设备扩展及数据库实例扩展，两个达到的目的是不一样的：
- 一个是可以稀释实例分布（因为毕竟也是考虑到成本，有可能物理设备是复用的，会存在一个物理机上跑着一个 MySQL 集群的主，同时还跑着别的集群的从实例，所以通过这种物理设备的扩展，可以通过切换并移动 MySQL 的实例，来减少物理设备的容量压力）。
- 另一个是可以稀释数据分片（实例数量的扩展，会涉及到分片数据的在线移动。这个经过我们的测试，发现其实会对局部的交易会产生一定的影响）。
4）迁移备份
- 通过 DataX 工具实现异构分批次迁移数据，这个也是在云缴费平台从传统的 Oracle 到 EverDB 的过程中所采用的方式，并在这个过程中完成了字符集转换。像原来 Oracle 的字符集可能有一些与 MySQL 不太一致的地方，可以通过这种文本落地的方式，把这个转换完成。像这种系统数据量比较大，我们在迁移的过程当中也做了一些批次的拆分，有一些不变的例数据，可以提前进行迁移，其实在真正实施的当天，迁移的数据是很少量的一部分。
- 数据备份为分集群整体备份以及单库备份，并支持额外的备份网络。毕竟这种分布式架构本身对网络的依赖度就非常高，如果要是与业务或者节点之间的通信采用同一个网络的话，备份是有很大可能会干扰正常的业务的。集群整体备份这块儿，其实是备的完整的集群拓扑，它还原出来的其实也是一个完整的集群拓扑；单库备份是一个逻辑备份，可以实现相对来说灵活一点的数据恢复。
5）开发应用
- 支持分布式事务。
- 支持事务、悲观锁以及全部隔离级别。
- 支持绝大部分 MySQL 语法（不是全支持，像我印象中，有一些像 left join 之类的支持程度是有限的，因为毕竟它的解析是靠 grid 来完成的，所以它的语法在这层的逻辑实现上是有一定的限制的）。
- 有限支持函数（min、max、count、sun、avg），视图（只可进行 select 操作，不能做 update 操作），过程（过程内不支持函数调用）。
- 不支持触发器、定时任务、临时表。
所以在开发上面，可能确实和原生的 MySQL 是有一定的区别的，但是已经可以满足我们目前大部分的应用逻辑设计的需求了。
3、EverDB 分布式数据库测试重点
在整个改造的过程当中，数据库测试算是我们的一个重点工作，主要集中在两方面：
1）测试场景设计
这次数据的迁移改造，我们一共设计了 30 余个测试场景，其中主要包括：
- 各功能节点的故障切换（因为相对传统的架构来说，虽然不集中了，但是功能节点变多了。同时也摆脱了传统的小机，因为现在用的都是 X86 的服务器了，所以它硬件的故障率可能是有一定上升的，所以我们模拟了每个功能节点的故障）。
- 节点间网络故障（因为网络整个的交易链路比原来的长了很多，所以跨机房或者是网卡的网络故障都有可能发生）。
- 集群动态扩容（也是比较体现分布式数据库优势的）。
- 不同背景压力对联机交易的影响（因为大部分系统还是有批量业务的，就会涉及到一些大的事务的处理，所以我们对于这种背景压力对于联机的影响也是比较关注的）。
- 极端情况下的备份恢复（比如说集群完全不能对外停服，或者是各个不同的节点 crash 之类的）。
- MGR/MS 对比（一开始我们挺倾向于使用 MGR 的这个架构的，毕竟它也是 MySQL 原生出的集群模式。但是经过测试对比，发现还是主从半同步的效率高一些，而且现在 MGR 确实技术还不是很成熟和稳定，所以我们最后部署上是选择了主从半同步）。
2）测试关注的指标
- 各故障场景的影响范围（因为毕竟按预期，是想将整体全局的故障转换成局部的故障）。
- 交易总体受影响时间时长。
- 交易失败笔数。
- 响应时间变化。
- 节点间网络流量（主要还是跨机房这块儿的，因为同城跨机房可能不光是有分布式数据库的流量，还会有业务的流量，或者是其它数据同步的流量。所以可能这种流量之间，对于带宽的要求也是使用分布式过程当中比较需要注意的点）。
4、云缴费系统实施重点
在云缴费系统实施的过程当中，也有一些重点，简单给大家介绍一下：
1）逻辑设计
- 分片表 ： 是数据库里最大的一张表，里面可能记录着日志、流水等。像这种表，是一定要有一个合适的分片键的，而且我们要把握好分片的数量。对这种大表的访问、拆分，平均分配到各个分区，只有实现了这部分的数据打散，才能真正对数据库的性能和访问效率有一个提升。所以几个大表之间可能同时还会存在一些 Join 的情况，所以我们这次在数据库的设计上，对这些大表都选择的相同的分片键，这样一笔交易进来，它可能带着相同的分片键，只会到一个实例里的一个数据库里去。所以它通过这种方式，减少了跨库甚至是跨机房的这种 Join，来避免由于这些操作而增加的交易成本。
- 全局表 ： 在缴费系统里，数据量有限，修改较少，读取较多。此类表会由 grid 这层把这些表复制到所有分片，可以和各分片进行本地 Join。我们的总体目标就是为了让它规避这种跨库。
- 普通表 ： 数据量有限，修改读取都较少。此类表集中存储不分片。这时候如果需要取得数就是临时 Join 一下，不需要和分片表 Join，不会有太大的成本和开销。
2）开发设计
- 连接驱动：和 MySQL 没有什么区别，基本上语法遵从 MySQL 的协议就可以了。
- 开发过程中尽量避免使用存储过程。相对来讲，这次做的应用改造就是将交易逻辑变得简单化了，把原来复杂的地方都给优化掉了，同时也选择了相对合理的字符集，因为这个系统原库的字符集其实不太合适，所以借着这个机会把这个问题解决掉。
- 分布式数据库存在多个接入 IP，需合理设计负载均衡和故障重连机制。因为刚才那张架构图中，它是从应用连接到 F5，再从 F5 分发到每一个中间件节点，中间件节点再到 MySQL。中间件节点到 MySQL 是长连接的，但从 F5 到中间件这层是不能用长连接的，因为如果要是这个时候用长连接，可能就会失去 F5 负载均衡的作用，所以在这种情况下，又要用短连接，又要保证在出现分布式事务的时候不能因为连接中断导致分布式事务失败（或者如果没有分布式事务，可能一笔交易中，需要做多个 DML 操作，可能因为短连接断开了导致它做了 3 个 DML，最后一个没有做成）这种情况肯定是不可能出现的。所以这时候我们调整了一下短连接的配置，让短连接的配置足够长，然后 F5 的连接断开释放由应用层来控制。比如说做十笔交易之后断一次。所以这块儿的负载均衡是靠这个来设计的。
3）批量设计
- 在批量这块，原来在 Oracle 环境里并没有做到与数据库的一个完全隔离，这次在分布式改造中，也是对这块儿做了一个优化。所以在隔离的情况下，我就不能让批量运行环境成为一个单点。所以就对批量故障的冗余、重试、数据检查及校验进行了重新设计。因为批量设计中也会涉及到一些分布式的事务，所以这块儿的数据的检查和校验也是设计的一个重点。
- 优化批量逻辑，减少跨分片 Join 及复杂 SQL。因为复杂 SQL 对于分布式来说，很多产品对于复杂 SQL 的支持还是很有限的，可能跑起来的效果也达不到预期。
- 批量拆分，充分利用分布式数据库资源。
4）试运行方案设计
刚才提到的 bridge 的工具，就是我们现在在试运行，以后会正式运行的一个主要的逃生方案。这种新技术产品带来的架构风险，一定要有逃生方案才能比较有信心在上面跑，在极端情况下，可以将新架构隔离开，让它回到相对来讲比较传统的架构上去。
目前云缴费架构已经算是改造完成上线了，但是它并没有完全接轨 Oracle 的真实交易，是在应用层做了一个转发，把发给 Oracle 的交易同步发给 EverDB 一份，然后通过这个试运行阶段，来验证产品的兼容性、稳定性。这个也算是个过渡阶段吧，因为只有经过真实生产的全量交易的压力后，我们才敢把其它的交易完整切过去。
所以这块儿的设计也挺重要的，如果直接就新上的话，可能会出现各种各样预期外的问题，解决起来可能也会无从下手。我们利用交易转发的机制，还在验证这种新架构的运行模式。对这种并行试运行的方案还有逃生方案，都要进行充分的测试，最终目的就是保障数据安全，同时这种逃生环境要能承载一定量的业务运行，毕竟它节点数不会有分布式那么多，所以如果业务全部切过来的话，它可能运行起来会遇到一些资源征用之类的问题。
5、云缴费系统部署架构
这张图是云缴费系统部署架构的一个真实的 1:1 的物理图：
它前面是 APP 的数量，一共是 24 台，后边用两个 grid 节点，然后有两台备份的服务器，和两台逃生的服务器。中间的区域全是 MySQL 的集群，全都是主从，采用的是一主三从的模式，目前是双机房运行。每个机房里有一主一从，另一个机房里有两从，然后通过配置，我保证同机房和跨机房有两个节点是数据强一致的，另外一个节点就不管了。这样如果发生故障的话，由 grid 这层会告诉它哪个节点的数据是最新的，是一致的，这样就会切到那个节点。
6、云缴费系统试运行总结
目前云缴费系统试运行也有半年了，这里是对它简单的一个总结：
1）分布式改造收益
- 处理能力横向扩展性提升，摆脱传统 IOE 的瓶颈。
- 降低对高度存储的依赖。因为刚才那张部署图里，所有的机器都没有用存储，像 EMC 或者其它牌子的存储，都没有在用，实际上就用了本地的 NVME 的闪盘；这个性能确实比存储要高很多，所以它其实从一定程度上弥补了网络上链路边长带来的损耗。
- 全局故障降低为局部故障。就是可能某一部分数据不可用，比如 8 个集群，哪怕一个集群整体都挂了，从也全挂了，但我可能还有 7 个集群，至少还有八分之七的对外服务是好的。
2）运维方案积累
因为这个对于我们来说也是第一次做这种比较大的改造转型，所以在监控指标及监控方案、故障场景的应急预案、分布式数据库的技术标准 & 规范等，都是通过这次的探索和迁移总结出了一些经验。
3）产品自身完善
- 提升集群整体运行工稳定性。这方面还是有提高的空间的，尤其是在架构上，我们也在尝试把一些像 ZooKeeper 这种小的组件与其它的组件做整合，减少各功能节点的离散程度，毕竟节点越多，出问题的可能性就越大。
- 对各分布式组件进行功能增强。因为通过这次开发和上线工作，也发现了数据库架构中的一些问题。
- 优化部署架构。
4）技术难点
目前我们碰到的一个技术难点就是交易全链路监控分析。因为这个交易链路从外部到前端的 F5，再到 AP，再到 F5，再到 grid，再到 MySQL，包括可能 grid 之间（也就是中间件节点之间）可能会有些数据同步，MySQL 之间也会有些数据同步，所以这个交易链路实际上比以前变得是太长太长了，所以现在如果某一笔交易慢了的话，可能在一些有日志的节点上，或者说日志做的比较完善的话，可能还是有迹可循的。可是如果网络抖动了一下，或者是出现一些延时的问题，目前看这种全链路虽然不是不能监控，但至少还没能实现一笔交易完整的一个追溯的过程。
五、EverDB 后续发展规划及里程回顾
1、后续发展规划
1）近期
增强运行稳定性，提升分布式事务性能。目前来讲，我们对于 XA 事务的处理可能性能上还有一定的优化空间，同时我们也希望这种数据库能够支持国产 ARM 平台和国产操作系统，能够接近于全系的安全可控标准；
2）中期
- 我们想简化部署方式，来实现轻量级的部署。而且像中间件的组件还有 bridge 的组件，我们想应用到单元化架构里去，就是把它拿出来，不一定就只能在我们这个架构里用。因为它本身就是松耦合的，拿到别的场景下，一样可以比较好的发挥它的作用。
- 还有一个就是扩展运行数据采集能力。因为数据这个东西其实在运维的过程当中是非常重要的，Oralce 做的最好就是 AWR 报告，其它不管是传统商业产品，还是新生的开源产品，在这方面还是比较欠缺的。所以我们想通过运行数据的采集，加上对数据的分析，来实现帮助数据库的运行状况能够长期保持在一个稳定良好的状态之下。
3）远期
如果说的再远一些，就是希望支持更多种底层数据存储引擎，不仅仅是 MySQL 了，可能还会有金融其它的数据库产品，并通过这种方式来扩展我们的应用场景。
以上就是我们后续想对分布式架构做的一些主要的工作。
2、里程回顾
这里展示了我们整个的一个里程碑，从开始改造到现在经历的一些比较重要的时间节点：
- 18 年，启动了技术路线的调研。
- 19 年第一季度完成了方案的选型，同时这个项目也正式地立项。其实这中间经历了大概有半年的时间，调研的过程我们还是收获很大的，因为我们看到了同业或者是互联网都在用什么样的产品，用什么样的架构，走什么技术路线，这些作为我们的参照依据，最终才有了 EverDB 的立项。
- 19 年 11 月，我们完成了 EverDB1.0 版本的开发。
- 后面时间很紧张，用了大概两个多月，就把云缴费基于 EverDB1.0 的测试完成了，并且做了投产试运行的工作。目前是处于全量交易转发的阶段。之前 1 月的时候，我们只过来了八分之一的量，后面通过不断观察数据库的指标，还有运行的稳定性，慢慢开到了半量、全量。
- 今年 5 月，我们启动了相应的升级项目，想后续对它整体的功能和组件做一些增强及优化。
其实架构转型，收获还是很大的，对于分布式的一些优势、劣势，包括它能做什么，不能做什么，如果没有完整地做一次的话，了解的就没有这么深入和具体。以上就是我今天给大家分享的全部内容。
Q & A
Q1：分片集群一致性备份策略是怎么样的？跨机房切换后性能下降后怎么和应用联动的呢？
A： 是这样，关于备份，是可以在 grid 层面获取到每个数据节点的一致性点的，可以通过这个一致性点，对后端的 MySQL 做一个相应的备份。关于跨机房切换后性能下降的问题，从 1:1 的架构图里，可以看出，我们做了服务器数量上的冗余保障，即便只在单边机房运行，每个服务器上也只有一个主节点，不会出现切换后一台服务器存在多个主节点导致的资源争用问题。
Q2：MySQL 使用的是什么版本呢？
A： 目前使用的还是 MySQL 5.7.26，暂时还没考虑 MySQL 8。MySQL 8 我们也在学习当中，因为它目前出现的时间也不算太长，相对来说现在比较稳定的还是 MySQL 5.7.26 或者 MySQL 5.7.28 这种版本。
Q3：跨机房的延时怎么解决呢？
A： 其实跨机房的延时很难解决，因为你要保证数据一致性的话，跨机房的延时是一定要等的，就像 CAP，可能保了一致性，就要牺牲一些别的东西。这个可能不同的领域有不同的权衡吧，也许对有些能够牺牲一致性的业务来说，对这块儿就可以把延时问题规避掉。但是涉及到转账，这种账务问题，可能还是没办法解决掉延时。其实在发生故障切换的时候，我们必须要保证另一个机房是有一份完整的数据的。
Q4：分片表主要就是业务流水，全局表就是类似人员信息这种主数据？
A： 差不多，这个也主要是在开发层做的设计。对于表的分类大致是这种方向，因为其实就是流水表、日志表最大，这种表在原来的 Oralce 的部署里面就已经做了一层甚至两层的分区了，只不过它提供的存储还是在一个里边。在这块儿，如果将分片表按照分片键做了拆分，实际上就已经部署到不同的物理分区上了。
Q5：选择合适的 MySQL 字符集，选了什么，utf8mb4 吗？
A： 是的，用的就是 utf8mb4。
Q6：分布式，是否涉及到多个库完成一个事务？若有，如何保证事务完整执行？
A： 分布式肯定是要涉及多个库的，这个实际上是已经跨了物理的分区和我的 MySQL 实例的，这个目前在云缴费的批量交易里是存在的，其实大部分联机都规避了这个问题，所以在批量交易里有这么个事务，就是用的 XA 的事务协议，来保证事务的完整性。
Q7：数据库节点变多，是如何做到备份统一调度的？
A： 这个其实跟刚才 Q1 是一样的。实际上我们备份的时间还是选择在业务相对低峰的时间段进行的，可能凌晨几点这样，因为确实在获取一致性点的时候，对业务是有点影响的，所以当节点变多的时候，影响可能会有点放大，不过也不会太大，而且又是凌晨两三点的那种基本上交易比较少的时间。所以还是通过数据一致性点来做的统一的调度。
Q8：分布式数据库，多大尺寸时，得再拆库？或者，达到其它什么指标时，得考虑再拆库？
A： 这个主要还是看物理分区的容量。因为这个用的不是存储，而是 nvme 的闪盘，也是为了保证效率，所以这个盘的扩展数量肯定是有限的。还有就是 CPU 和内存，当这几方面，还有单点承受的一些 QPS、TPS 指标，当它承受到一定量，可能会有些风险的时候，可能就会提前做一些数据节点或分片水平扩展的操作。
Q9：备份是如何发起的，有统一的数据库备份平台吗？
A： 备份发起使用 control 的那个管理组件，它实际上是一个外部的管理台，用它来调度响应的备份策略的。
Q10：对 SQL 有限制么，中间件会有内存溢出的风险么，mycat 落地中间数据，有内存溢出风险
A： 目前还没出现，关于溢出这个问题，目前在测试环境应该是压到了差不多 10000 左右的 TPS，目前看着是没有什么问题。
关于对 SQL 的限制，是指语法吗？语法上是确实有些限制的，比如对于过程的调用、临时表表或是 left join 之类的操作，具体的限制要通过开发手册作为指引，但目前基本已经支持了绝大多数的开发语法。
Q11：可以实现在线扩缩容吗？具体原理是怎样的？
A： 有两种，一种是要扩物理的机器，一种是要加 MySQL 实例。扩机器的时候，就是挪动主从的位置，其实也就是一个切换，对局部影响有，但比较小，从测试结果来看，比加实例挪数据的影响小得多。
Q12：读写分离是基于中间件还是业务层处理？
A： 是通过中间件来做的，具备读写分离功能但目前未启用，主要是因为试点业务没有这个需求，所以不是目前主要的测试目标。
Q13：DDL 变更怎样保证所有节点一致，如果某个节点执行失败，怎么处理？
A： 其实现在对于 DDL 的原子性还是没有一个很好的保障的，但是对于 DDL 操作是有相应的检测命令的，所以在 DDL 场景下，可能还是需要通过操作的标准规范来避免这个问题。比如说，DDL 命令下去之后，要返回一下我所有 DDL 修改的结果，因为它毕竟涉及到多个实例，目前还没有很强的一个 DDL 保障。
作者介绍：
于树文，光大银行资深 DBA
- 目前在中国光大银行信息科技部数据库管理团队主要负责分布式数据库建设项目，推进行内技术架构转型等相关工作。
- 从事数据库运维管理工作十余年，在数据库的性能优化，升级迁移，高可用容灾等方面具有丰富经验。