单集群400TB，OceanBase稳定支撑快手核心业务场景

一款日均超过千万人访问的短视频 App 快手，面对高并发流量如何及时有效地处理用户请求？通过在后端配置多套 MySQL 集群来支撑高流量访问，以解决大数据量存储和性能问题，这种传统的 MySQL 分库分表方案有何问题？快手对分布式数据库展开选型并最终大规模落地 OceanBase 的原因是什么？本文来自于快手运维负责人筱虫对此次快手数据库解决方案进行的思考和经验总结。

快手 APP 是中国流行的短视频和直播应用之一，其内容涵盖生活的方方面面，希望以技术赋能，用科技提升每个人独特的幸福感。在快手上，用户可以用照片和短视频记录自己的生活点滴，也可以通过直播与粉丝实时互动。自 2011 年成立至 2021 年上市以来，快手日活用户已达数亿，一方面促使直播、电商等业务飞速增长，另一方面，底层系统也面临着前所未有的压力。虽然，传统方案一定程度上缓解了快手的存储问题，带来了性能上的提升，但同时运维复杂性和不可持续性也为公司的可持续发展带来了挑战。

随着订单业务量及业务数据的迅猛增长，快手原来采用的 MySQL 解决方案在存储和性能方面的表现愈发不足，以订单业务为例，订单业务总数据量超过 150TB 时，MySQL 的存储瓶颈和性能问题越来越明显。为缓解该类问题带来的业务影响，我们选择分库分表方案来应对。

但是，业务持续增长使底层数据库的分片数不断增加，以至于线上 MySQL 分片数达到 300+，不仅没能彻底解决存储问题还引入了更大的运维复杂度，需要我们不断对应用进行改造和适配以解决分库分表带来的问题。而短视频 App 的业务峰值 QPS（每秒查询率）能达到百万以上，对性能要求极高，在此情况下，单个集群需要很多的 MySQL 节点，无法做到在业务高峰期保证业务请求及时返回，并且不论是中间件还是数据下游所有链路，都需要很重的硬件以支撑产品稳定性方案。

此外，我们的 TP 业务要求具备强事务、实时读写的能力，同时伴有 AP 需求，为了保证系统稳定可靠，需要采用 MySQL 接 ClickHouse、Elasticsearc 或 Doris，可能需要更多的数据副本，这就带来了更高的硬件成本。

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

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

让我印象比较深的是，单表超过 10TB 且不断增长的情况下，使用该数据库架构做 DDL，预计需要一周，而使用 OceanBase 则不到一天即可完成。并且，由于部分业务持续增长，需要不断加表、加源数据，使得 DDL 操作繁多。该数据库本身是小分区的方式，在数据量大的情况下会导致整个 region 数量变得特别大，一旦出现宕机或扩缩容、节点替换需求时，很可能影响业务稳定性。相应的，OceanBase 采用大分区，像上述的业务操作可以在小时级，最多天级完成。

目前，我们短视频 App 有 8 个 OceanBase 集群，机器规模已经超过 200 台物理机，数据量超 800T，最大集群数据量超 400T。我们最初使用 OceanBase 3.1 版本、后期升级到了 4.2 版本，所有的集群都在提供线上服务，其中有核心系统交易核对系统和支付网关业务系统，也有替换 MySQL 主库来承担高并发写入的业务。在迁移到 4.1 版本后，集群本身对于业务的收益和稳定性都有显著提升。下面以快手的两大核心业务场景举例，介绍 OceanBase 的落地效果。

（一）交易核对场景

作为短视频平台，快手有对应的电商业务满足大家在刷视频时的购物需求。一般情况下电商的日均流量 QPS 表现平稳，大概 8-9w。进行大型直播时，用户流量剧烈增长，一般情况下 QPS 能快速增长至平时的十倍甚至百倍，达到百万级别，即使数据量压缩也会达到百余 TB。

在直播期间：

业务对延迟极度敏感，对 TPS 有着极高的要求，通常情况下要求延迟为 ms 级，如无法在规定时间内完成请求则会影响核对结果，出现数据不准确问题；
电商业务对系统稳定性要求非常高，因为业务和交易密切相关，一旦系统出现故障或者异常抖动时，影响业务，会产生资损。

在引入 OceanBase 前，交易核对场景读写都在 MySQL 上面，针对大表问题，我们采用传统的分库分表方案，将大表拆成多个小表，将业务读写流量拆分到多个 MySQL 实例。由于分库分表方案的跨库数据一致性和跨库事务原子性，在复杂和异常情况下容易出现数据不一致问题，导致数据核对时出现不正确的结果。比如：没有退款、扣款金额不准确，出现资损问题。

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

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

（二）支付业务场景

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

特点1：数据量大

支付业务的数据量相比交易核对业务更多，单集群的数据量可达到百余 TB，最大的集群数据量已经超过 400TB，同时单表数据量达到 10TB 以上。

特点2：复杂聚合

该业务写入比查询流量高很多，而所有的后台查询都要通过支付网关，需要对大量数据进行聚合查询，可能会 join 多张表以及有可能是几十个甚至是上百个，业务对查询本身的性能要求高。

特点3：频繁 DDL

因为查询不是固定的，为了查询速度更快，业务需要频繁加索引来加快查询速度。在之前的方案里，数据写入 MySQL 集群的同时，同步数据到 Elasticsearch 集群，利用 Elasticsearch 的搜索能力提供给业务进行复杂 AP 查询分析。新方案在一定程度上能满足业务的需求，不过以下存在三个问题。

数据实时性不够好：数据在写入 MySQL 之后再同步到 Elasticsearch，实效性较差，可能因为 MySQL 的持续大量写入而产生数据延迟；
成本高：因为接入了 Elasticsearch 集群，业务不仅仅需要考虑 MySQL 成本，同时还有 Elasticsearch 集群的硬件成本和维护成本；
运维更复杂：需要同时兼顾 MySQL 集群和 Elasticsearch 集群的运维。

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

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

目前，我们使用 OCP 管理多套集群，一套 OCP 管理 OceanBase 的 8 套集群，OBServer 节点数超过 190 个，集群扩缩容、监控、告警都可以通过 OCP 完成，非常方便。另外，业务侧非常喜欢使用 ODC，这 OceanBase 的一个查询平台，需要验证数据是否写入成功，以及写入结果是否正确。因为通过界面操作即可完成日常的业务访问数据库需求，同时版本更新快，处理问题及时，所以百人级别业务都在使用。

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

OceanBase 高度兼容 MySQL 引擎，极大降低开发和使用门槛。业务人员可以沿用 MySQL 的使用方式来使用 OceanBase，而不需要改变使用习惯，同时在数据迁移方面，因 OceanBase 兼容 MySQL 协议与语法，所以能够做到平滑迁移，可大幅降低业务迁移和改造成本；
运维更加高效与便捷。单集群替换 300+ 套 MySQL 环境，运维管理成本大大降低，同时管理更加方便；
数据同步性能提升。数据从上游写入到下游 OceanBase 响应延迟更小，数据同步速度更快，同步延迟时间减少 3/4；
OceanBase 同城三机房部署架构，实现 RPO =0，RTO<8s 的容灾能力。同时，可以在异地增加一个只读 Zone 提供本地的读服务，提升查询效率。同城容灾以及本地读等功能为业务提供稳定性和性能双重保障；
OceanBase 具备灵活的资源扩展能力，根据业务实际发展情况可以动态的进行计算和存储能力的线性扩展。支撑海量数据的存储和计算，同时很好地应对未来的业务增长要求；
相比传统的集中式数据库 MySQL，OceanBase 在存储层面有极致的压缩能力，有效降低企业使用数据库的硬件成本，比如帮助我们节省了 50 台机器。

我们在使用 OceanBase 的过程中，也发现了需要优化的细节。首先，我们使用的 4.1 版本还没有兼容 MySQL Binlog，需要通过逻辑的 select 把数据导出来，再同步到大数据平台去做兼容。不过 OceanBase 4.2 版本已经兼容，我们计划接下来做尝试。

其次，在运维工具方面，OCP 部分告警信息不是特别清晰，排查问题会有些不方便，扩容上百台机器需要手动重试，不过从官方得知，在 OCP 4.2 版本中，以上提到的问题都已经得到了解决。

当然，我们明白任何一款产品都不是万金油，一定是优点与不足并存。后续，我们也希望持续深化和 OceanBase 社区合作，统一版本并在新版本中发挥 OceanBase 在存储和性能方面的显著优势。同时，基于 OceanBase 兼容 MySQL Binlog 格式，对接更多的下游生态，接入更多的业务，我们也将参与 OceanBase 代码贡献，深度参与社区共建。