mysql分片后影响备份吗_光大银行分布式实战：国内最大缴费平台的数据库架构转型...

本文根据于树文老师在〖deeplus直播第231期〗线上分享演讲内容整理而成。(文末有获取本期PPT&回放的方式，不要错过)

于树文

光大银行资深DBA

目前在中国光大银行信息科技部数据库管理团队主要负责分布式数据库建设项目，推进行内技术架构转型等相关工作。

从事数据库运维管理工作十余年，在数据库的性能优化，升级迁移，高可用容灾等方面具有丰富经验。

我今天分享的主题是《高并发场景下，光大银行分布式数据库的架构转型实战》。

光大银行也是很有魄力的，拿出了一个重要的业务系统进行一次试点，做了一次这种分布式架构转型的项目。我有过十余年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解析、事务控制和数据存储与访问。像数据复制、备份恢复、可用性切换、数据迁移、操作调度、开发接口、权限管理、对象管理、监控报警等等，这些都是它整个的一个生态。这些工具有没有、高不高效，就决定了运维的工作能不能更好的开展。

所以，分布式数据库其实就是将传统数据库的各技术组件通过松耦合的方式部署，通过网络之间，会有一个相互的协同工作，达到分散压力&