从 v3.1 到 v4.3，OceanBase 稳定支撑快手 PB 级核心业务场景

本文摘自《OceanBase社区版在泛互场景的应用案例研究》电子书，点击链接即可获取完整版内容。

作者：胡玉龙，快手运维负责人

快手 APP 是中国流行的短视频和直播应用之一。作为普惠数字社区，快手不仅让数亿普通人记录和分享生活，更帮助人们发现所需、发挥所长。平台汇集内容涵盖生活方方面面，用户可以通过照片和短视频记录自己的生活点滴，也可以通过直播与粉丝实时互动，在技术赋能基础上提升用户幸福感。

那么，像这样一款日均访问人次超千万的短视频 App，当面对高并发流量时该如何及时有效地处理用户请求？我们早期的做法是：通过在后端配置多套 MySQL 集群来支撑高流量访问，从而解决大数据量存储和性能问题，但这种传统的 MySQL 分库分表方案存在不少问题。而在引用 OceanBase 后，核心业务场景中的技术兼容性、运维便捷性、数据同步性、业务稳定性、资源扩展能力等性能都有了极大提升。同时，在使用 OceanBase 过程中，我们对版本进行了持续更新，积累了不同版本的实践经验。

一、从 MySQL 分库分表到“增强版 MySQL”

自 2011 年成立至 2021 年上市期间，快手日活用户突破数亿。如此大规模的流量，一方面推动了直播、电商等业务飞速增长；另一方面，却给底层存储系统带来了前所未有的压力。虽然通过传统数据库分库分表方案在一定程度上缓解了压力，性能得以提升，但运维的复杂性和不可持续性为系统埋下了更大的隐患。

以 App 负载的“订单业务”为例，当业务总数据量超过 150TB 时，MySQL 的存储瓶颈和性能短板越来越明显。为缓解这些问题对业务带来的影响，我们选择通过分库分表方案应对。然而，业务持续增长使底层数据库的分片数不断增加，以至于线上 MySQL 分片数达到 300+，不仅没能彻底解决存储问题，还引起了更大的运维复杂度。我们需要不断对应用进行改造和适配以解决分库分表带来的难题。

短视频 App 的业务峰值 QPS（每秒查询率）能达到百万以上，对性能要求极高。在此情况下，单个集群需要很多的 MySQL 节点，无法做到在业务高峰期保证业务请求及时返回，并且不论是中间件还是数据下游所有链路，都需要高性能硬件以支撑产品稳定性方案。

此外，我们的 TP 业务不仅要求具备强事务和实时读写的能力，同时伴有 AP 需求，为了保证系统稳定可靠，需要采用 MySQL 结合 ClickHouse、Elasticsearc 或 Doris 的方案，且可能需要增加更多数据副本，这无疑会带来更高的硬件成本。

我们意识到，分库分表方案只能尽可能缓解而无法从根本上解决问题，亟需一款既能满足业务需求，又具备高性能、灵活扩展，还能降低运维复杂度的分布式数据库解决方案。

在分布式数据库的探索之路上，我们最初尝试了某品牌的分布式数据库。但在使用过程中发现其在写入性能、运维方式等方面存在问题，比如运维平台比较简单、 难以满足 DBA 的需求，且很多内核问题难以得到解决。因此，我们尝试选择了 OceanBase。

通过对比测试发现，当单表数据量超过 10TB 且不断增长时，某品牌分布式数据库架构进行 DDL 操作预计需要一周时间，而 OceanBase 仅需不到一天即可完成。由于部分业务持续增长，需不断加表和添加源数据，导致 DDL 操作繁多。该分布式数据库采用小分区的方式，在数据量大的情况下会致使整个 region 数量显著增加，一旦出现宕机、扩缩容或节点替换需求时，很可能影响业务稳定性。相比之下，OceanBase 采用大分区，上述的业务操作可以在小时级甚至最多天级单位内完成。

二、核心业务场景应用 OceanBase 的收益

截至 2023 年年底，快手短视频 App 有 8 个 OceanBase 集群，机器规模超过 200 台物理机，数据量超 800T，其中最大的集群数据量超 400T。最初，我们使用 OceanBase 3.1 版本，后期升级到 4.3 版本。所有集群都提供线上服务，涵盖核心系统交易核对系统、支付网关业务系统，以及替换 MySQL 主库以承担高并发写入的业务。在迁移到 OceanBase4.1 版本后，集群在业务收益和稳定性方面均得到显著提升。下面以两个核心业务场景为例，介绍 OceanBase 的实际落地效果。

（一）交易核对场景

作为短视频平台，电商是快手最重要的业务组成之一。通常情况下，该业务日均流量 QPS 保持在 8-9 万的平稳水平 。当进行大型直播期间，用户流量会急剧增长，QPS 会迅速飙升至平时的十倍甚至百倍，达到百万级别，此时数据量即便经过压缩，也会达到百余 TB，这就要求数据库的快、稳和抗压。

• 毫秒级延迟。业务对延迟极度敏感，对 TPS 有着极高的要求，通常情况下要求延迟为毫秒级，如无法在规定时间内完成请求则会影响核对结果，出现数据不准确问题。

• 稳定性更强。如果数据库抖动会导致大量的核对失败，在交易核对场景下，数据库不仅需要在日常流量峰值时保持长期稳定，还需要在流量高峰时没有抖动。

• 抗压力强。当数据量超百 TB，单集群数据的单副本达到 20TB 左右时，随着单表数据的增大，对系统资源消耗会越来越多，进而影响数据库的响应时间。因此，读写请求峰值达到 QPS 百万级要求数据库足够平稳，响应时间不受影响。

在引入 OceanBase 之前，交易核对场景的读写操作均在 MySQL 上进行。针对大表问题，我们采用了传统的分库分表方案，将大表拆成多个小表，并将业务读写流量拆分到多个 MySQL 实例中。然而，分库分表方案在跨库数据一致性和跨库事务原子性等方面存在局限，容易在复杂和异常情况下导致数据不一致问题，进而使得数据核对结果不准确。例如，可能出现没有记录退款以及扣款金额不准确等现象，最终引发经济损失。

经过方案调研和选型，由于 OceanBase 分布式架构具备天然的水平扩展能力，因此在数据量不断增长时，只需要水平扩展集群的存储和计算能力，即可解决大表查询和存储问题；同时，本身具备原生分布式能力，更擅长处理分布式事务。使用 OceanBase 后，上游业务直接写入 MySQL 集群中，每一条数据在写入上游 MySQL 分片时，会通过 Binlog 实时同步到 OceanBase 中。在数据核对查询时，系统会同时对上游 MySQL 和下游 OceanBase 进行相同的查询，并对查询结果进行比对，从而保证整个账务系统中订单状态的正确性。

图 1 显示了“交易核对业务线上表现”，日常 QPS 在左上侧，数据量约为 9 万左右，右上侧为响应时间, 平均时延不超过 10ms, 峰值时延达到 1 万毫秒，这是由于每晚凌晨全量合并后，业务会额外启动一个特定线程去删除大量历史数据, 导致此时时延偏高, 但业务方对此可以接受。下方的两个曲线图是写入量，按事务统计的日均 TPS 在 1 万左右，响应时间为 5-10 毫秒，OceanBase 响应时间满足业务对延迟的要求，同时系统稳定性得到保障。

图 1 交易核对业务线上表现

（二）支付业务场景

支付业务是电商的实时业务，一方面是面向商家、客服查询直播收益，另一方面是支付网关相关的聚合查询，该业务有三个显著的特点。

（1）数据量大。 支付业务的数据量较交易核对业务更为庞大，单集群数据量可达百余 TB，最大集群数据量已超 400TB，单表数据量也达到 10TB 以上。

（2）复杂聚合。 该业务写入流量远高于查询流量，且所有后台查询均需通过支付网关，涉及对大量数据进行聚合查询，可能会聚合数十甚至上百张表，业务对查询性能要求高。

（3）频繁 DDL。 因查询不具备固定性，为提升速度，业务需要频繁加索引。此前方案是在数据写入 MySQL 集群的同时，同步数据到 Elasticsearch 集群，借助 Elasticsearch 的搜索能力，为业务提供复杂的 AP 查询分析。虽然新方案在一定程度上能满足业务的需求，但仍存在以下 3 个问题。

• 数据实时性不够好：数据在写入 MySQL 之后再同步到 Elasticsearch，实效性较差，可能因为 MySQL 的持续大量写入而产生了数据延迟。

• 成本高：因为接入了 Elasticsearch 集群，业务不仅仅需要考虑 MySQL 的成本，同时还有 Elasticsearch 集群的硬件成本和维护成本。

• 运维更复杂：需要同时兼顾 MySQL 集群和 Elasticsearch 集群的运维。

在引入 OceanBase 之后，其在线扩展性轻松解决了大数据量的存储问题，HTAP 能力在保证数据写入的同时提供实时查询分析。在该业务场景中，OceanBase 的复杂 SQL 分析能力不弱于 Elasticsearch。此外，OceanBase 的在线加索引能力支持业务可以随时进行 DDL 变更。采用 OceanBase 替换原 MySQL+Elasticsearch 方案后，不仅省去 Elasticsearch 服务及硬件，还大幅降低 MySQL 硬件成本，整体机器资源节省达 50%，且性能满足业务查询要求。如图 2 左侧为 MySQL+ Elasticsearch 方案，右侧为 OceanBase 方案。

图 2 数据写入和查询分析的 MySQL+ Elasticsearch 和 OceanBase 方案

图 3 是支付业务的线上表现，写入量在 5-7 万之间，查询不到 1 万。蓝色的线表示在删数据，绿色的线是写和读的响应时间。

图 3 支付业务线上表现 

基于 OCP 能便捷完成集群扩缩容、监控与告警，其管理着多套 OceanBase 集群。此外，业务侧非常喜欢使用 ODC，这是 OceanBase 的一个查询平台，用于验证数据是否写入成功以及写入结果是否正确。因其界面操作满足日常数据库访问需求，且版本更新迅速、问题处理及时，所以百人级别的业务都在使用。

三、从 OceanBase3.1 版本升级至 4.3 版本的经验和效果

到了 2024 年 9 月，快手的数据量快速增至 PB 级，并从原来 OBServer 190 多个节点增长到近 300 个，线上共部署 9 套 OceanBase 集群。在数据量剧增的情况下，我们开始升级至 OceanBase4.x 版本。其中，数据量较大（20T 以上）的集群已经升级至 4.2 或 4.3，还有一半数据量较小的集群（10T 以下）仍在 3.x 版本中。那么，相较 3.x 版本来看，4.x 版本性能有哪些提升呢？

从图 4 来看，4.x 版本的数据似乎没有增长。但如果在 3.x 版本不升级的情况下，随着近一年业务的发展，数据量会增长约 1.5TB，数据节点数量也会提高一倍。这就体现了版本升级的妙处，OceanBase4.x 版本相较于 3.x 版本能够更极致地压缩数据，节省存储空间，从而节约存储和机器成本。

图 4 4.x 版本和 3.x 版本集群列表对比

此前，我们使用分布式数据库某 DB 来支撑支付业务，它使用 range 分区，每个表自动分裂，在写数据量较大时无法利用所有机器的性能，导致在流量较大的情况下性能较差，如果遇到流量高峰，就需要业务限流才能保证底层查询的稳定性。

在引入 OceanBase 3.1 版本后，使用 hash 分区，写入性能大幅提升；DDL 速度更快，至少能保证业务流量高峰时不再限流。升级到 OceanBase 4.3 版本后，成本收益进一步提升，复杂查询速度更快，基本在 10ms 内完成。我们支付业务中还有一些 AP 查询需求，在使用 OceanBase 3.1 版本时，只有行存，业务需要忍耐一定的查询延迟，OceanBase 4.3 版本的行列混存特性使查询更实时，写入延迟在 1ms 以内。

图 5 是支付业务在升级到 OceanBase 4.x 版本后的线上表现。

图 5 支付业务在升级到 OceanBase 4.x 版本后的线上表现

此外，在使用 OceanBase 3.x 版本时，业务人员希望将不完美的功能进行优化，例如非分区表。当业务量小时，单表很小也无需分区，随着业务量的增长，单分区表可能会把单 CPU 打满，或者磁盘占用较满导致单副本变得庞大。此时 OceanBase3.x 版本不支持从单分区变为多分区，而 4.x 版本能够做到。同时，业务人员希望数据库的查询速度可以更快，OceanBase 4.3 版本的行列混存特性可以极大提升复杂查询的性能。

除解决业务需求外，我们升级 OceanBase 版本的重要因素还包括跟随版本迭代积累运维经验，保持业务版本不会落后太多。

总的来说，快手在升级 OceanBase4.x 版本后成本更低、查询更快。以支付网关为例，在 3.1.x 版本中，该集群规模为 65 节点，是线上环境规模最大的集群。升级前数据量 450TB，升级后机器规模缩减为 45 台，数据量压缩至 330TB。机器成本降低了 31%，数据量比之前压缩了约 27%。

在一些 TP+AP 场景下，最初我们使用 OceanBase 3.1 版本替换 MySQL，满足业务的 HTAP 需求。升级为 OceanBase 4.3 版本后，更加稳定、性能更高、分析耗时更快。另外，在 OceanBase 3.x 版本里面，我们需要将 OceanBase 数据同步到下游对接大数据生态，但受限于 Binlog 不支持所以操作起来不太方便。在 OceanBase 4.2 版本中，Binlog 兼容了 MySQL Binlog，这个问题得到了解决。

同时，我们也感受到了 OceanBase 生态工具侧的迭代升级。例如 OCP、ODC 等在 2022 年之前容易出现升级、扩容方面的问题，现在我们用 OCP 集群 12 台机器运维管理 9 套集群都没有出现扩缩容或监控告警等相关问题，当 OCP 诊断到问题时能够自动解决，无需人工干预。

四、使用 OceanBase 后的六大收益

从上述两个核心业务场景可以看出，使用 OceanBase 后，快手取得的收益显著，总结而言包括以下六点。

（1）OceanBase 高度兼容 MySQL 引擎，极大降低了开发和使用的门槛。业务人员可以沿用 MySQL 的使用方式来使用 OceanBase，无需改变使用习惯。同时，由于 OceanBase 兼容 MySQL 协议与语法，能够平滑地进行数据迁移，大幅降低业务迁移和改造成本。

（2）运维更加高效便捷，单集群可替换 300+套 MySQL 环境，显著降低运维管理成本，提升管理效率。

（3）数据同步性能提升，从上游写入到下游 OceanBase 的响应延迟更小，数据同步速度更快，延迟时间减少 3/4。

（4）OceanBase 的同城三机房部署架构实现 RPO=0，RTO<8s 的容灾能力。同时，可在异地增加只读 Zone 提供本地读服务，提升查询效率。同城容灾以及本地读等功能为业务提供稳定性和性能双重保障。

（5）OceanBase 具备灵活的资源扩展能力，可根据业务发展动态进行计算和存储能力的线性扩展，支撑海量数据的存储和计算，应对未来的业务增长要求。

（6）相比传统集中式数据库 MySQL，OceanBase 在存储层面极致的压缩能力，有效降低了企业使用数据库的硬件成本，比如帮助我们节省了 50 台机器。

五、未来规划

未来，我们希望持续深化和 OceanBase 的社区合作，统一版本并在新版本中发挥 OceanBase 在存储和性能方面的显著优势。同时，基于 OceanBase 兼容 MySQL Binlog 格式，对接更多的下游生态，接入更多的业务，我们也将参与 OceanBase 代码贡献，深度参与社区共建。

「老纪的技术唠嗑局」不仅希望能持续给大家带来有价值的技术分享，也希望能和大家一起为开源社区贡献一份力量。如果你对 OceanBase 开源社区认可，点亮一颗小星星 ✨ 吧！你的每一个 Star，都是我们努力的动力。

https://github.com/oceanbase/oceanbase