【对话ACE】第七期｜双11，如何保证数据库稳定可靠？

 

每年双11，各个电商平台的流量突增，全民都在喜迎这场购物狂欢。除了流量增长，各个平台的交易数据也达到了全年的峰值。对于数据库和运维人员也将迎来年度大考，支撑这场大考一切业务指标的背后，是底层技术体系不断迭代升级。

OceanBase原生分布式数据库已经连续9年稳定支撑双11，积累了很多关于大促期间的运维经验。所以，在双11即将到来之际，《对话ACE》第七期邀请 OceanBase 解决方案架构师、前蚂蚁集团数据库团队DBA专家白超，Oracle ACE 惠星星，一起就“双11如何保证数据库稳定可靠”这个话题展开了深入探讨。

---

 

以下为对话实录，欢迎大家阅读、收藏！

 

Q1

您觉得该如何界定与保证数据库的稳定可靠？

 

惠星星：

数据库的稳定性可以通过RTO（Recovery Time Objective）来界定，它是数据中心灾难恢复方面的重要参考指标，表示业务从中断到恢复正常所需的时间。保证数据库的稳定可靠，在上线前需要做好“建转运”以及运行期间的管理。

首先我认为要对日常运维人员做好培训，因为人员稳定性、误操作以及技能等各种各样的问题都可能影响数据库的稳定运行。在这里借用恩墨学院的12大箴言：原理通透、思路清晰、操作娴熟，做好人员的培训以及夯实基础能够一定程度上来避免由于人员操作造成的数据库隐患。

作为数据库运维人员，有时候会认为自身的工作意义不大、重复性较多，创造性不高，但要结合到具体的业务场景中，自身价值就能够体现出来，比如我维护的这套金融系统，正是由于基础工作做得扎实才能保证银行的日常业务顺利开展，让老百姓能够正常的存取款，营业厅正常办理业务。所以大家一定要有主人翁的意识，认识到自己工作的重要性以及对整个社会做的贡献。

第二，成熟的架构以及解决方案能够保证系统的稳定。以Oracle数据库为例，RAC 是兼容高可用和高性能的一个数据库架构，能够有效提高整体的业务性能，消除单点隐患。在我维护的Oracle数据库中，部分企业就有明确的文件要求重要的系统必须改造成RAC架构，由此可见它的重要性。Oracle的存储级软件ASM，通过不同的冗余程度去消除部分存储级的隐患。在系统上线前，我们都会给其加载一定的业务压力，来检测是否能够稳定运行，这个时候我们通常会挑选例如账务的出账收费、业务办理等核心功能进行业务层以及特殊语句SQL的压力测试，总之我们会通过不同维度的数据库管理方法保证系统的稳定。另外，Oracle还会定期发布PSU的补丁，来消除由于软件造成的隐患。Data Guard作为Oracle备用数据库解决方案，可以在不同的区域机房建设实现数据库实时同步，帮助数据库提高应对灾害的可靠性。

第三，规范的建转运管理流程也是保证数据库稳定运行的因素之一。在数据迁移以及业务系统测试无误后，可以提交试运行以便提前发现软件或性能问题。除此之外，运行期间要完善数据库监控，包括存储层服务器层等监控，有条件的也对数据库进行常态化的监控与优化，每天扎实优化一条sql，对整体的数据库性能有很大的提升，当然应急预案的制定以及演练对于数据库稳定运行也是必不可少。

因此，保证数据库的稳定运行需要涉及到很多方面与细致的工作，这也是作为DBA的价值所在。

 

Q2

OceanBase 支撑双11已经九年了，在主从切换中，通过哪些途径保持数据的强一致性？

 

白超：

“如何保证主从切换数据的强一致性”这个问题，在双11的交易支付场景中，要保障数据不能丢失，它的重要程度堪比银行或者其他金融行业的核心业务。作为前蚂蚁集团的DBA，我有很深的体会，当传统数据库架构中主从切换的过程中出现问题，会损害具体的业务。在蚂蚁集团全面迁移至 OceanBase 之前，传统的主备架构需要在数据的一致性以及可用性之间作出选择。2015年蚂蚁集团还有一部分核心业务存在于Oracle数据库上，当时市政工程施工挖断了电信光缆，导致数据库的主实例与备实例处于无法通信的状态，因为考虑潜在的数据丢失风险，无法快速切换至备机房恢复业务。如果是普通的业务，在接受少量数据丢失情况下可以强行切换备库。但对于蚂蚁集团涉及资金的具体交易中，如果在未知的状态下，强行切换可能导致无法估计的损失。

OceanBase 数据库基于无共享集群的分布式架构，通过 Paxos 共识协议来保持数据的强一致，它基于多数派的协议，保证在任一时刻，只有得到多数派的认可，一个节点才能成为主节点提供读写服务。如果三个当中的一个或是五个当中的两个节点发生故障，也能实现业务数据零丢失。

为了保证数据一致性，OceanBase 还从设计的角度出发，对例如面对数据的静默错误（因为硬件原因磁盘或内存发生位翻转等导致）这类极端场景，都会进行在线的事务日志校验与数据对比，以确保不同的用户在读到不同副本上的数据都是一致的。除此之外，在没有业务的场景下我们还可以选择开启后台的任务对基线上的数据做比对，通过多个维度规避主从不一致的问题。因此在蚂蚁集团或是支付宝业务切换到 OceanBase 之后。业务上彻底告别了过去因为切换可能导致数据不一致、需要人工修复以及订正的情况。

 

Q3

您觉得双11，数据库的性能优化应做到哪些？

 

惠星星：

在实际的运维过程中，可能会通过加内存或者升级服务器这种硬件堆积的方式来提升整个数据库的性能，但这种方式是比较简单粗暴的，往往服务器配置升上去后，业务响应依然达不到理想的效果。因此这也验证了我刚才讲到的维护数据库一定要重视运维人员的技能提升。其实通过一条SQL的优化就能达到几倍或是上万倍性能提升的效果，如果只是简单堆积服务器，数据库的性能和以前还是一样。所以我认为，数据库优化中，一定要分析根本原因来解决问题。

Oracle数据库有很多可观测的监控工具，例如ASH报告、性能收集等机制，以及基于数据库的基础统计信息的监控工具，这些辅助工具加上运维人员基础技能提升来定位到数据库的根因，从而集中资源有的放矢来进行数据库的优化，而不是通过简单堆积服务器这样的方式来提升性能。

以双11大促场景为例，我们可以根据历史数据对特殊场景做提前的业务评估，在压力测试的过程中去找到系统性能的瓶颈，是内存不足，是CPU不足，还是存储性能不好或是SQL没有写好等等原因，因此用好数据库也是非常关键的，不管是商用数据库还是开源或分布式数据库，一定要了解它的特性发挥出最大的性能优势。

 

Q4

双11，除了处理高并发，还要让用户有良好的的购物体验，如何实现系统持续稳定运行？

 

白超：

双11电商大促是一个有计划的高流量场景，最终目标为保障用户的购物支付体验，从整体来看需要保证从应用到数据库再到底层存储的一整条链路能够达到“丝般顺滑”，这对于一个大型的业务系统其实是一件非常困难的事情，尤其是面对双11巨大的流量以及众多的人口基础。除了数据库系统的稳定运行，还需要从业务设计的角度出发，才能为用户提供更好的体验。在支付宝，我们在业务层面中在整体上做了”单元化“的设计，相当于把所有的用户业务的请求切分为若干个单元，每一个单元的业务的部署和数据库部署都是自包含。任意单元故障不影响整体业务。OceanBase 在单元化架构中的主要体现在于极致弹性，意味着我们能够在任一时刻将任意1%的流量划转到任意一个城市的机房，来解决某个单元或机房容量不足等异常的情况，由此可见流量的调度划转能力非常重要。OceanBase 的多租户多副本设计为蚂蚁单元化的架构提供了弹性、稳定的数据底座，保证了用户体验。

此外，为了保持数据库系统的稳定运行，OceanBase 在SQL方面也做了诸多创新，除了在上线或大型活动之前对SQL异常的执行计划或统计信息问题做自动化巡检，针对如何保证交易业务的极致稳定方面也做了特殊的设计。我们知道大部分的在线交易场景都是以相对简单的SQL为主，追求快速、稳定的响应时间的，而当这类业务遇到一些随机的汇总查询，并积累到一定量级时，就可能会影响数据库的稳定。对此 OceanBase 引入了大查询队列的设计，对发送到数据库上的SQL进行解析，当内核通过SQL ID的识别被判定为大查询时，便会在下一次该请求发到数据库时将这条SQL被放到隔离的大查询队列中，队列有一组单独的隔离资源，能够保证在流量突然增高的情况下，也会让大查询在一个资源有限的队列中排队等待而不会过多的占用关键的在线短交易，这个设计能够很好满足OLTP场景下对响应时间以及稳定性的严格要求。

除了数据库的SQL角度，OceanBase 也从具体的高并发业务场景出发，保证数据库的稳定运行。比如电商业务中，大促热门商品的秒杀，大量用户的抢购等场景中，需要对商品库存做到及时的扣减，对应到数据库中就是某一行的高并发更新；支付宝的业务中，商家大规模高频转账交易也要求余额及时更新，如果高并发场景不能满足性能要求，就会直接影响商户的交易总量以及整体系统的吞吐率。OceanBase 直面解决高并发场景下的问题，单行更新慢在本质上是持有锁串行更新的问题，等待日志完全提交再释放锁，是导致并发无法提升的关键因素。OceanBase通过工程上的巧妙设计实现，让解行锁的时机提前，使解行锁和日志提交同步的过程异步化，从而大幅度的提升单行并发的更新能力，这个功能可以让同城部署的数据库单行TPS提升至3-5倍，跨城部署的环境中提升百倍以上。这对于蚂蚁的双十一以及高并发场景是非常优秀的特性。

结合 OceanBase 的内核能力和智能化运维平台，使得我们也可以很好的提升应对故障或者抖动的能力。当出现彻底的宕机或是因为硬件问题导致当前及诶单数据库彻底的不可用的情况，基于 Paxos 的分布式共识算法可以在30秒内选举出一个新的leader（在 OceanBase 4.0中这一指标可以做到8秒以内），并且对应用弱感知。对于因网络出现抖动、时而发生不稳定连接的场景，我们需要快速隔离异常流量，此时可以通过 OceanBase 有主选举的方式将流量快速隔离到其他健康的节点上。将有主选举的内核能力结合沉淀了专家经验的故障感知系统，再配合决策执行模块，这就是蚂蚁DBA打造的的故障自愈系统，通过将DBA专家的经验转化为一颗根因决策树，再辅助机器学习的一些手段，我们可以将常见的抖动、宕机或容量不足的问题通过这套自愈系统在第一时间做自动感知和恢复，所以从整体的体验以及稳定性的提升来说，OceanBase 与内部的DBA平台做了很多积累，由此才能在历年大促中做到“如丝般顺滑”。OceanBase 正是在严苛的环境中历经挑战，不断在业务中打磨，才能在既具备高性能和极致弹性的同时，变得更加稳定可靠。

 

Q5

云趋势下，关于大促场景下如何保证资源稳定保障？

 

惠星星：

在传统行业中，云数据库有低成本、快速部署以及稳定等优势，不同企业根据系统的业务特点以及企业管理的规范，数据有可上云与不可上云的划分，可以尽可能地将符合条件的数据上云以便我们有更多的精力维护更有价值的业务，不可上云的资源便可以根据其业务特点提前做好资源的储备与扩充，以确保在类似于大促的场景下满足业务的需求。

 

Q6

针对不同的业务场景，OceanBase 是否具有不同的应急处理及相关预案？

 

白超：

首先是针对异常SQL的处理预案，我们都知道很多时候数据库的异常来自于异常的SQL，比如一些业务中部分SQL由执行几百次突然上升到一个小时执行上万次，此时对其限流就需要依赖数据库端的能力。针对这个问题，OceanBase 可以在内核层面限制相同SQL ID的SQL并发度，将其从每分钟执行上千次降到数十次，甚至降到次实现对其“熔断”，也就是说在应用侧无法做降级和熔断时，数据库是有这个能力完成的。同时限流操作可以结合业务等级进行，负责应用业务的人员根据SQL的重要程度，在SQL洞察平台中进行打标，当线上真正出现问题时，预先被打了标记可以被限流的SQL会由平台自动做限流操作，同时DBA也可以在第一时间做处理，这就是OceanBase 在限流能力上建设的部分体现。除此之外，在 OceanBase 中，如果出现SQL索引选择不合理或者表连接方式不正确等计划相关的问题时，我们可以通过OUTLINE 绑定的方式，直接在线干预SQL执行计划，限流与OUTLINE很大提升了我们应急处理的能力。

其次针对异常流量的预案，如果这些读的流量来自应用层，它们非常关键不能限流，当面对突发的大流量时，OceanBase 作为一个多副本的数据库，可以在单个副本流量不足时将读流量打散到所有的副本上，让集群每一台机器都参与到业务流量处理中，这就是我们内部讲的“切弱读”的方式，它能够很大缓解异常流量或者是缓存失效、雪崩的场景，为业务的稳定性提供有效保障。

蚂蚁集团有上万台物理机，容器与实例数量更是数以十万计，在这样的规模下，在运维中偶然出现的“黑天鹅“事件积累到一定的程度就会变成必然事件：例如某些批次硬件的固件出现问题对集群产生影响，或是操作系统中罕见的bug触发等。蚂蚁集团针对内部的核心集群还设计了异构FO兜底方案，应对最极端的故障场景。可以说，OceanBase 从微观局部到整体架构上都有相对完备的应急处理方案。

 

Q7

这种大促环境下，线上的告警和容灾预案您觉得应该如何规划？

 

惠星星：

线上告警分为监控与告警两部分。在监控方面，成熟数据库厂商有多年的积累与众多的服务客户基数，他们的监控软件能够很大程度上帮助我们降低成本。除此之外，大家也可以根据自身的业务特性自主编写一些监控项。在告警方面，一些无效告警会对日常运维工作造成影响，建议可以将告警进行不同的等级划分，我们再根据不同的告警级别采取对应的应急措施。在业务层面，在最高等级的告警情况下我们可以通过业务层面进行隔离以确保核心业务的稳定。Oracle的容灾预案也是比较成熟的，比如两地三中心方案，在容灾预案的建设过程中分为物理级与逻辑层，那我我个人更倾向于物理层这样保障的预案。

 

Q8

关于双11场景下，OceanBase 如何保证性能和成本的平衡？

 

白超：

所有的企业在数据库到了一定的规模之后都会关心如何增效如何降本的问题，蚂蚁集团的业务规模较庞大，对应的成本优化的挑战与要求也就越高，针对这个问题，OceanBase 在计算与存储方面都做了很多的工作。

在计算层面，如何提升资源的利用率是一大问题。OceanBase 通过多租户的模式在大集群中实现资源的池化，相当于租户之间的计算资源与存储资源隔离。

在存储层面，不同于Oracle或MySQL数据库，删除了插入的数据无法直接释放对应磁盘空间，只有在重整表空间或是降低高水位后才能够回收这一部分空间，而开启压缩又会降低性能。

OceanBase 在降低存储成本方面，第一个层面的设计是通过对LSM存储架构的利用，它的顺序存储特性能够保证每个数据块紧凑存储，每日增量数据在做合并时都会将原来修改的块重新写一遍，天然规避了数据空洞的问题。

第二个层面，OceanBase 的存储引擎使用了编码压缩的技术，能够压缩冗余的行与列数据。

第三个层面，LSM Tree架构存储引擎的增量活跃数据都在内存中进行，导致基线磁盘当中的数据不会被直接更新，因此我们可以在基线数据中使用一些高压缩的算法而不影响性能表现。

以上三个层面综合起来，可以让我们在存储10TB的外部数据集文件时在OceanBase 压缩到3TB甚至更少。对于外部客户，比如我们服务的银行金融客户，他们之前使用的Oracle实例较少做过高水位线回收或是重整表空间的操作，导入到 OceanBase 中可能达到近90%的数据压缩比，存储成本压缩能够很好的量化。除此之外，OceanBase 中只用作事务投票保持数据一致性的日志副本可以使用更低配置的机器，又能保持集群的 Paxos 三副本或五副本成员列表的完整性与有效性，这也是降低成本的一个手段。

由于蚂蚁集团的基础设施规模非常庞大，所以我们在技术架构方面做了很多infra底层的工作，比如通过不同的机型，使用容器化结合OB多租户的机制进行混部，以及使用存储混部的技术等，从整体上不断提升资源的利用率。

 

Q9

在国产数据库蓬勃发展的浪潮下，商业数据库的稳定性和商业价值两者应该如何平衡？

 

惠星星：

在我接触的客户中，企业的信息系统按照重要程度划分为不同的等级。随着中美贸易战、俄乌战争的影响，可以将自主可控提上日程，比如在业务允许的情况下给国产数据库提供更多的应用场景与机会，类似于“备胎计划”，从既不考核也不核心的系统中应用，经过实际业务的打磨最终达到核心系统的国产数据替换。类似于OB这样成熟的数据库以及多年来支撑双11大促的业务打磨，肯定可以支持我们的信息系统，我们也要以更开放的姿态给国产数据库提供更多的应用机会，让我们的业务逐步测试、接纳以及应用它，最终依赖它！

 

Q10

双11的容量会是平常的几十倍，OceanBase 如何实现扩容并且能平滑实现云端弹性操作？

 

白超：

双11数据库的容量能力要求会成倍提升，在 OceanBase 诞生之前，我们需要历经几个月甚至半年做例如拆分扩容、压测等储备，不仅会耗费大量的人力，垂直水平拆分等操作也会面临较大的风险，这些问题都在OceanBase 时代得到了解决，比如在大促前短时间内将某些机房的数据扩展到云机房上，用云机房的资源应对双十一的流量，高峰期过后再快速缩容回日常规模。

由于 OceanBase 副本均衡能力对应用是近乎透明的，结合无状态路由达到对应用近似无感知的状态。比如从A机房将副本弹性到容量更充裕的B机房中，dba不用关心数据库的数据拷贝、一致性校验等问题，只需要在批量的迁移平台上触发任务，迁移完成后，OceanBase 通过前端proxy组建逐渐将新流量路由到迁移弹性之后的节点。整个过程是在后台进行达到应用无感知的状态，相比于传统方案，DBA的幸福感也很大程度的提升。

面对规模化运维的难题，蚂蚁的DBA团队还推出了规模化变更工具OMP平台，真正将蚂蚁数据库批量变更的能力提升到一个新高度。DBA只需要制定一个扩容或者配置变更，或者是弹性策略下发到平台，OMP会自动灰度向目标机房执行变更。目前蚂蚁集团SRE DBA规模不到20个同学，但能够很好的支撑蚂蚁全站所有数据库运维的操作，包括大促期间的业务保障，都依赖于OB工具化与智能化。

OceanBase 这样灵活的弹性扩缩容方案，大促前快速扩容，大促后快速缩容，能够为中小型企业有效降低成本，减少开支。