进军公有云这一年，OceanBase做了什么-编程知识

*本文转载自微信公众号“机器之心，ID：almosthuman2014”

如今，数据库市场正在迈入新的竞争阶段——一场云上的角逐。

2022 年，中国公有云数据库市场规模首次过半[1]，预计未来占比将进一步扩大。许多中国的数据库厂商也抓住了云计算的发展趋势，积极进军云数据库。

但是，这并不容易。许多企业已经在使用传统的数据库产品，要说服他们使用或迁移到云，需要打消客户对新技术的疑虑，解决数据迁移的技术和业务挑战，提供强大的数据安全和隐私保护功能，以及，在保证产品质量和服务水平的前提下，提供具有竞争力的价格——以数据库产品的固有「粘性」，这是一件极难做到的事情。

云数据库市场的参与者众多，每个玩家都在努力提供更好的产品和服务，争取获得更大的市场份额。

作为原生分布式数据库的领先产品，OceanBase 在 2022 年 8 月宣布推出云数据库 OB Cloud。经过一年的发展，OB Cloud 在全球赢得了众多客户，包括新零售行业的海底捞、二维火和客如云，制造业的理想汽车，互联网行业的高德、携程、快手、作业帮、翼鸥教育、GCash，以及跨境行业的洋葱集团、纵腾集团、递四方等。

那么 OB Cloud 做对了什么？本文主要从四个方面进行了剖析。

2023 年 5 月，理想汽车自动驾驶和车云等系统批量上线 OB Cloud，以应对大量云场景带来的挑战。这一决定的背后，是其产线运维系统在 OceanBase 上一年多的稳定运行，实践了 RTO（Recovery Time Objective，恢复时间目标）秒级的极致体验。

RTO 对汽车制造为什么重要？

汽车制造流水线是一个高度复杂和自动化的系统，会产生大量的数据，包括机器数据（生产线上的各种设备和机器的运行数据，如温度、压力、转速、电流等）、工艺数据（产品制造过程的各种参数，如加工时间、材料使用量、产品质量数据等），制造执行系统（MES）数据（如生产计划、库存管理、订单信息、物料需求计划等）。

一些大型的汽车制造商可能会每天产生高达数 PB（1PB=1000TB）的数据。

使用这些数据进行分析，可以帮助制造商更好地理解生产过程、优化工艺，提高生产效率和产品质量。然而，处理如此巨量的数据需要强大的数据库系统，这也是许多制造商在数字化转型过程中需要面对的一个主要难题。

随着理想汽车近年来的高速发展，产线系统的数据量激增，其数据库系统在处理大量并发请求或大规模数据时开始出现性能瓶颈，对生产线的稳定运行构成了严重威胁。对车企来说，产线就是生命线，保证产线的平稳高效运转至关重要，产线上的任何一个系统出现故障，都可能导致停产，而每一秒的停滞都意味着巨大的人力和资源损失。

在这样的背景下，理想汽车开始自研智能制造操作系统 Li-MOS，并急于寻找一款极致稳定、可靠、扩展性强的数据库，以应对系统稳定性和高可用的挑战。OceanBase 投产至今，始终保持零故障稳定运行。理想 DBA 负责人赵海军回忆。

RTO 是一个衡量系统在出现故障后恢复正常运行所需时间的重要指标。这个时间包括了检测到问题、启动恢复过程，以及恢复操作直到系统恢复正常运行的全部时间，这一数字也成为衡量在线应用的数据库故障恢复水平的核心指标。

2014 年，OceanBase 在业界首次提出 RTO<30 秒，并且整个故障恢复过程完全自动不再需要人工参与，在当年双十一支付宝交易过程中全球首次做到分布式数据库不丢数据（RPO=0）、不停服务（RTO<30s）。如今，RTO＜30s 已经成为分布式数据库业界的事实标准。

2022 年，OceanBase 4.0 首次实现 RTO<8s，真正将故障恢复时间从分钟级降低到秒级。

从 30 秒到 8 秒，这短短 22 秒的提升看似简单，但背后涉及了大量技术和工程的挑战。就像 F1 赛车比赛中的换胎过程，每一秒的缩短都是对技术、基础设施、团队协作，以及最重要的，对应用场景和业务流程的深刻理解和精准控制。

在 4.0 版本中，OceanBase 做了非常大的架构调整，把最底层的选举和一致性协议做了重新设计和实现，并做了大量的优化。选举方面，不再依赖于节点之间的绝对时间，而是完全基于消息驱动，将整个选举 Lease 的时间缩短到了 4 秒以内。不仅如此，在更上层的 RPC 框架内部重新设计了一套故障检测机制，当主节点出现故障时，系统会直接进行有主的改选，可以在百毫秒的级别就把主的服务切换到一个新的 leader 上。一致性方面，所有的备节点都能实时并行地去回放主节点写入的内容，从而确保了在主节点故障后，备节点能够立即承担服务。并且，基于 Paxos 算法和动态日志流技术的创新，OceanBase 在单机模式下可以跑出超过MySQL 的性能，在测试场景下，可以做到接近 200 万的 TPS。

作为共识协议的「本源」、容错性最好的 Paxos，其工程实现难度也是最大的。OceanBase 早在 1.0 版本就完整独立地实现了基于 Multi-Paxos 算法的日志同步机制，并在极致场景下打磨多年。正是因为一开始就完全自研，所以能够实现这些在底层架构上的创新。

升级至 OceanBase 后，理想汽车的产线执行系统数据库抖动频率平均下降约 80%，对于常见的故障事件真正做到了「先恢复、后分析」，大幅提升系统运行稳定性，结合智能运维体系，理想汽车的产线执行系统能够在无人值守的情况下，迅速完成故障的自动恢复，实现汽车产线系统数据库的「无人驾驶」。

OB Cloud 完全支持 OceanBase 4.x 版本，提供同样的高可用服务。在产线运维系统已稳定运行 17 个月后，理想汽车决定，继续将自动驾驶和车云等构建于云上的数据库系统迁移至 OceanBase 的云上版本，继续在云上实现严苛的 RTO 目标。

再来看一个故事。

作为菲律宾最大的电子钱包应用，GCash 被称为「菲律宾的支付宝」，注册用户 6000 万。然而，业务的快速扩展，其存储和计算资源成本也呈现出迅猛的增长，给公司带来了巨大的成本压力。

2020 年，GCash 日均交易量已达百万级，每个月都有超过 18TB 的新数据涌入，而且还在以大约 10% 的增幅继续上涨。为了处理这些数据，运维团队不得不投入大量资源进行数据拆分，不仅消耗了大量的人力和时间，还可能对系统的性能和稳定性产生影响。与此同时，数据存储空间的压力也在不断增大，数据库管理员（DBA）经常需要通宵达旦地进行数据清理和归档以释放存储空间。然而，这种解决方案只是暂时的，不能从根本上解决问题，反而进一步增加了运维成本。

在最繁忙的时候，运维团队需要管理超过 200 个 MySQL 实例。面对如此大的业务量，系统很难平稳地进行变更以支持新的业务，在极端情况下还可能会出现数据丢失。

GCash 迫切需要一个新的云上的存储解决方案，以应对数据快速增长带来的成本挑战。

最终，凭借高效、可扩展且高性价比的数据存储服务，以及 OceanBase 在金融支付领域的丰富积累，GCash 选择 OB Cloud 作为其新一代的存储底盘，OB Cloud提供了同 OceanBase 完全一致的数据压缩体验。

OceanBase 自研 LSM-Tree 架构的存储引擎，能根据数据存储的特征进行自适应编码压缩，提供高效的数据压缩能力。在过去服务用户的经验中，存储空间甚至可以降低到用户原有数据库系统存储空间的十分之一。

通过压缩来降低存储成本是再自然不过的选择。但是，数据压缩最终目的是降本增效，降本不能牺牲效率，因此，实现高压缩比的前提一定是先保证高性能，其次，是做出更适合实际业务场景的数据压缩。

通过使用自主研发的数据编码压缩技术，OceanBase可以根据数据类型和分布特性，自动选择最合适的编码方式，在保证性能的同时，实现高效的数据压缩。假设需要存储这 15 个数字：「0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233」。我们可以选择直接存储它们，每个数字占用一个存储单元，共需要 15 个存储单元。或者，我们也可以根据这串数字的特性——每个数字都是前两个数字之和，选择在一个存储单元中写入「前 15 个斐波那契数」。这样，相同的信息内容，存储的数据量却大幅度减少。更重要的是，这种压缩过程是无损的。当然，这只是一个简化的例子，实际的过程要复杂得多。

除了能感知数据特征并按列进行压缩的数据编码（encoding），OceanBase还同时支持不感知数据特征的通用压缩（compression）。也就是说，可以对一个数据块先进行编码，然后再进行通用压缩，从而实现更高的压缩率。

这些数据编码格式考虑到了对查询性能的影响。不仅如此，压缩的路径也经过设计，不会降低计算效率和解压缩性能。

结果显示，借助高效存储引擎和云上高速的块存储服务，OB Cloud 使 GCash 的数据存储空间节省了 70%，数据库资源成本节省了 40%。这一结果大大超过了 GCash 的预期，为其带来了显著的效益，并使其能够更有效地服务持续增长的用户群体。

在现今的消费市场，新的流量模式和消费习惯正在不断涌现。

每年的节假日，尤其是七夕、双旦，对海底捞这类餐饮及零售类企业至关重要。在数字化转型过程中，系统在流量波峰与波谷的处理能力也直接影响到业务。

海底捞的进销存系统，就是个典型例子。以 2021 年上半年为例，海底捞仅在瓜果蔬肉类的采购总金额就超过了 28 亿元，覆盖新疆、贵州、云南等 29 个省市自治区，数据体量异常巨大，丝滑的数据处理关系着食材品质和及时供应。

随着业务快速增长，使用传统数据库的进销存系统面临越来越多的挑战。比如，全国门店的食材和物料进货、存储、销售及供应等数据，以及数据实时变化带来的高并发问题；门店销售单中的食材和物料变动必须与库存模块的数量保持一致，如果不一致可能会导致备货过量或缺货；订单状态不明确，会导致用户服务不到位，影响就餐满意度等。

每年的七夕、双旦，不仅是海底捞员工，也是系统数据处理最繁忙的时候，由于个别热销商品库存变化非常快，单条数据需支持秒级数千次的高变动频次，这也要求系统必须能做到实时分析汇总商品数量变化情况，以及时备货供应。

如何更灵活、更安全、更低成本地实现数据库灵活扩缩容，完美支持每次节假日的流量洪峰，成为海底捞最关心的问题。

为了更好地应对流量的急速变化，海底捞的业务数据库需要具备灵活的调整能力：在业务低峰期，以较小的规模稳定运行，减少资源浪费；在业务高峰期，快速扩容，以保障节假日的稳定运营。

针对海底捞的业务特点和需求，OB Cloud 以其从 OceanBase 继承的多级弹性伸缩能力，在云上打造了一个理想的解决方案。

在 OB Cloud 中，每一个业务（租户）拥有自己独立的资源。这些资源位于同一个资源池中，可以根据业务的实际需求进行动态调整。这种设计使得资源的使用更加精确，避免浪费。同时，这种设计也使得业务能够更快速地响应流量的变化，提高了业务的响应能力。

面对较大的业务流量，简单调整租户规格可能还无法满足业务需求，这时候就要在集群上做调整。在 OB Cloud 中，可以通过改变服务器的配置（垂直扩缩容），或者增加或减少服务器的数量（水平扩缩容）来适应业务需求的变化，而后者是 MySQL 等主备架构难以做到的。这两种扩缩容可以互相结合，提供更大的灵活性，有效地应对流量的突增和突减，保证业务的稳定性和效率。

在刚刚过去的七夕节，海底捞进销存系统经受了两倍于去年的流量峰值，但基于 OB Cloud 的加持，提升了 45% 的系统实时分析算力、降低 50% 的数据库整体成本，从容应对了节日大考。

OceanBase 还在一个更高的层面，探索业务和架构的灵活性：首次引入了创新的「单机分布式一体化架构」，小到使用公共云的个人小站点，大到使用私有云、混合云的银行核心系统、巨型电商网站，都可以在业务发展不同阶段根据自身特点，灵活满足性价比和高可用的需求，而不是受制于技术被迫接受一些他们并不需要的能力。

这也引出了一个新的挑战——如何在复杂的云计算架构和多样的计算场景中，提供一种统一而且高效的云数据库解决方案。

云计算已经从初期的公有云和私有云，发展到包含多个数据中心的混合云架构。这转变也让我们向更复杂的架构和混合云场景迈进。越来越多的企业开始在多个基础设施上部署应用和数据，一方面利用混合云环境的灵活性和快速响应，一方面可以为不同的应用场景选择不同的云基础设施，充分发挥各个云服务的独特优势。

例如理想汽车，其生产线制造系统在数据中心进行私有部署，而车辆云和自动驾驶系统则选择了多个不同的云基础设施，并且在公有云的多个地域进行部署，这样即使部分功能出现故障，整体服务也不会受到影响，保证车主的行车安全。

但是，这种模式也带来了很多技术上的挑战：不同数据库产品在不同云基础设施上的功能性能差异，增加了运维复杂度和资源整合难度；传统单体数据库难以扩展并存在单点瓶颈问题，无法满足如车联网系统这样的多地访问的低延迟需求。此外，虽然某些数据库产品解决了扩展性问题，但它们的一致性协议对网络延迟敏感，可能导致在远距离机房或网络环境不稳定的场景下产生写入抖动和服务不稳定，难以满足类似车联网、自动驾驶业务的低延迟要求，等等。

面对多基础设施的挑战，需要一种灵活、可扩展的混合云架构解决方案，能够统一管理和简化这些环境，同时还能提供一致的性能和功能。

OceanBase 不依赖专属硬件并能支持不同云基础设施，它采用了无共享架构。通过使用 OB Cloud，理想汽车可以在数据中心部署整套 OceanBase 平台，也可以在不同的云基础设施和云服务上提供一致的功能和管理界面，这大大提高了存储底盘的一体性和管理效率。同时，OB Cloud 的原生高可用架构可以在局部单点故障时快速自动恢复，甚至在跨地域部署的情况下也能提供稳定的服务，确保像联网车机这样的关键系统的安全运行，保证车主的行车体验。

现在，理想汽车借助 OceanBase 打造全球领先的制造系统，并在 OB Cloud 上实现车云业务跨云异地多活，产线连续性和业务稳定性得到保障。