硬件成本降 52%，快钱支付引入 OceanBase 后的降本增效

编者按： 在移动互联网时代，在线支付和移动支付已经成为大众的普通选择。尤其在国内，除支付宝和微信支付两大巨头外，还有许多第三方支付企业为商家和用户提供便捷的支付服务，如金融型支付企业银联商务、快钱；信用中介型支付企业拉卡拉、嘉联支付等。如何保证交易的正确性、实时性和安全性？这与技术架构底层的数据库服务息息相关。本文通过分享快钱公司的 DB 架构变迁及升级的方案和经验，解答上述问题。

作者：冷盛杰，快钱支付 DBA

快钱 DB 架构的历史变迁

快钱公司（快钱）作为国内领先的独立第三方支付企业，其产品丰富，包括但不限于人民币支付、外卡支付，代缴/收费业务，VPOS 服务，集团账户管理等，目前正在拓展跨境人民币结算业务。其支持互联网、手机、电话和 POS 等多种终端，为各类企业及个人提供安全、便捷和保密的综合电子支付服务。快钱曾荣获中国信息安全产品测评认证中心颁发的“支付清算系统安全技术保障级一级”认证证书和国际 PCI 安全认证，这是源于业务后方对技术先进性与安全性的持续追求，比如对于有着“系统心脏”之称的数据库，在其创立的 20 年间，已经历三次变革。

（一）最初阶段

在业务早期阶段，快钱使用的 MySQL 架构，如下图所示。

该架构的优点是

• 使用了 Keepalived，基本保证了数据库的高可用；

• 拥有 slave，基本可以做到读写分离；

• 小规模的数据情况下，MySQL 可以从容应对。

但是，Keepalived 固有的脑裂问题无法解决，比如一旦发生脑裂，就容易造成应用连接报错、数据不一致等问题，这是支付领域无法容忍的故障。 同时，因为 slave 是作为 M2 的备库，如果 M2 出现异常，slave 很难保证数据一致。

（二）MySQL 使用痛点

随着公司业务量的激增，原始的两主一备的 MySQL 架构已经无法满足业务需求，例如当时最大的一张核心单表达到 4TB，数据库性能、运维能力都难以支撑，且对业务扩展造成了影响。于是引入 MyCAT 作为分库分表的中间件，以及 MySQL 高可用方案 MHA（底层 MySQL 同步采用 GTID 机制）。

采用该架构能够短暂突破单机 MySQL 在性能、容量、高可用性等方面的瓶颈，且架构改造对应用几乎没有影响。应用程序只需连接 MyCAT 这一个入口点，使用标准的 SQL 和 MySQL 协议进行交互即可。MyCAT 负责解析 SQL，根据预定义的分片规则（如取模、范围、哈希、日期等）将请求路由到后端的物理数据库（分片节点）执行，并将结果聚合后返回应用。由于改造复杂性较低，对于开发人员而言，也无需过多投入。 但是缺点也比较显著，比如：

• 分布式事务支持薄弱，XA 事务性能低下。MyCAT 支持基于 XA 协议的分布式事务，但在跨多个分片节点执行时，性能开销极大，锁持有时间长，严重影响系统吞吐量。

• 缺乏最终一致性方案。对于需要跨分片强一致性的场景，MyCAT 没有内建的、成熟的最终一致性补偿机制。

• 跨分片 JOIN/子查询性能差。跨多个分片的复杂关联查询（JOIN）、嵌套子查询等，需要 MyCAT 从多个节点拉取大量数据在内存中进行处理，效率极低，容易导致内存溢出。

• 分片规则选择与管理不灵活。选择合适的分片键和分片规则至关重要且具有挑战性。一旦初始规则选择不当或业务变化导致规则不合理，进行数据重新分片（Resharding）是极其痛苦的操作，且风险较高。

• SQL 兼容性与调试不完整。虽然 MyCAT 兼容大部分 MySQL 协议和 SQL，但在某些特定语法、函数或复杂语句中可能存在兼容性问题或解析错误。

• 数据迁移与扩容需人工干预。初始数据导入和后续的节点缩容和扩容，通常需要人工进行数据迁移和重新平衡，过程复杂且可能影响在线服务。

值得一提的是，在高可用方面，相较于此前两主一备架构，MHA 能自动检测主库故障，在确认主库不可用后，能够秒级完成故障转移过程，包括选择最优从库、应用差异中继日志、提升为新主库、切换其他从库等步骤，最大限度地减少停机时间。另外，得益于 GTID 的特性，也可以最大程度减少数据丢失。

但是 MHA 架构具有潜在的脑裂风险，如果 MHA Manager 无法准确判断主库状态（例如网络分区导致 Manager 与主库连接中断，但主库实际仍在运行并接受写操作），它可能会错误地触发故障转移。此时会出现两个“主库”同时接受写请求，导致数据严重不一致。此外，MHA Manager 节点是单点，无法对自身进行高可用，如果 Manager 节点宕机，整个高可用管理功能（自动故障转移）将失效。而且 MHA 管理节点需要能通过 SSH 无密码登录到所有的 MySQL 节点以执行命令和复制日志文件。这带来了额外的安全配置和管理负担。

（三）DB 新架构的选型和需求

随着业务的再次激增，MySQL+MyCAT 的架构开始逐步受到成本、性能、高可用等挑战。

1.服务器成本高。

我们在 MySQL+MyCAT 的架构中通常采用两种分片模式，hash 分片 120 个 schema，range 按时间分片到不同的 schema。在我们的初步架构中 120 个分片分布到 24 个实例中，而每台 DB 服务器 4 个实例，每个实例 5 个 schema，底层采用 MHA 的架构时就需要 18 台 DB 服务器。再加上 MyCAT 的服务器，这将是一个庞大的集群。服务器成本随着业务数据量的增加而“水涨船高”，在公司降本增效的要求下，眼见该架构无法长久。

2.资源难以精准利用。

底层的 I/O、CPU、内存均为共享模式，即使 MySQL5.7 版本可以在线调整 innodb_buffer_pool_size，但依然无法做到更加智能的调整，一旦业务上线，很难根据业务的具体发展情况进行动态调整和按需分配。

3.无法快速定位。

从上文 MyCAT 架构图中可以看到，从应用程序到负载均衡层再到 MyCAT 再到 MySQL，是一条很长的链路，中间任一环节出现问题，都很难被快速定位。

4.危险的在线 DDL。

尽管我们将 MySQL 升级到 8.0 版本后在线 DDL 得到增加，但在分库分表的情况下，即便使用脚本和自动化运维，一旦大表进行 DDL 操作，依然存在主备同步延迟、DB 锁导致上层业务波动的风险。

5.高可用问题。

一旦 MySQL 在主从延迟的情况下发生切换，MHA 无法保证不丢数据。

选定 OceanBase，迁移的五个经验

针对我们在生产环境中遇到的种种问题，架构替换势在必行。我们结合业务情况和对市场中开源数据库的调研数据，注意到 OceanBase 社区版非常符合我们对新架构的要求，尤其是以下五个方面。

• 低成本：基于 LSM-Tree 的高压缩引擎，存储成本可降低 70% - 90%；原生支持多租户架构，同集群可为多个独立业务提供服务，租户间数据隔离，降低部署和运维成本。

• 高可用：独创 “三地五中心” 容灾架构方案，建立金融行业无损容灾新标准。支持同城/异地容灾，可实现多地多活，满足金融行业 6 级容灾标准（RPO=0，RTO< 8s）。

• 高兼容：高度兼容 MySQL，覆盖绝大多数常见功能，支持过程语言、触发器等高级特性，提供自动迁移工具，支持迁移评估和反向同步以保障数据迁移安全。可支撑金融、政府、运营商等关键行业核心场景替代。

• 水平扩展：可以实现透明水平扩展，支持业务快速的扩容、缩容，同时，通过准内存处理架构实现高性能。支持集群节点超过数千个，单集群最大数据量超过 3PB，最大单表行数达万亿级。

• 安全可靠：OceanBase 拥有信创资格，拥有完备的角色权限管理体系，数据存储和通信全链路透明加密，支持国密算法，通过等保三级专项合规检测。

迁移过程较为丝滑，不在此赘述，分享几点迁移经验。

第一，所有表必须有主键。每个表最多拥有一个主键列集合，主键列的数量不能超过 64 列，且主键数据总长度不能超过 16KB。如果一张表不存在主键，那么 OceanBase 的迁移工具 OMS 将无法正常迁移该表。

第二，外键约束问题。OMS 对于 MySQL 外键表的迁移有所限制，如果有外键约束的 MySQL 表需要迁移到 OceanBase，一定要在前期将外键的逻辑优化到应用中。

第三，合理设计分区表。在 OceanBase 中分区表的性能和功能比 MySQL 强大很多，所以在一张 MySQL 的大表迁移至 OceanBase 时，可以考虑是否将大表改造为 OceanBase 的分区表。但 OceanBase 总 MySQL 租户类型的分区表强烈不建议使用全局索引，这是因为 MySQL 租户下的分区表如果存在全局索引，在对分区进行 drop 或者 truncate 时会造成全局索引失效。

第四，参数兼容性问题。当业务迁移至 OceanBase 后，一定要注意相关参数的修改。这里举例两个常见的参数。

ob_query_timeout：该参数为 OceanBase 的 SQL 超时时间，默认只有 10S，所以一定要结合自己的系统进行修改。

explicit_defaults_for_timestamp：该参数在 MySQL 中控制 TIMESTAMP 列默认行为的系统变量，主要影响 TIMESTAMP 列的 NULL 值处理、自动更新特性及默认值设置。在 MySQL5.7 中，该参数默认值为 OFF，但在 OceanBase 中为 ON，所以建议根据源端数据库的情况进行修改。

第五，使用 OMS 迁移中间件架构的问题。在实际使用中，OMS 基本可以完美解决从 MySQL 迁移到 OceanBase 的问题，但 OMS 同步数据的原理是基于 MySQL 的 binlog，但分库分表的中间件只是一个路由和 SQL 解析的工具，无法提供类似 binlog 从而产生增量数据用于 OMS 的增量同步和反向同步，因此，我们对需要迁移的中间件架构进行了改造。如下图所示：

从图中可以看到，

• OMS 正向同步数据到 OceanBase 时，直接从分库分表底层的 MySQL 节点开始同步，对所有分片的数据在 OceanBase 层面进行汇总。需要注意的是，因为源端数据的表名和目标端的表名一致，OMS 用于数据汇聚后进行验证时，必须保证源表不但有主键还需要另外一个唯一键，这样才能进行数据校验比对。

• 因为我们在迁移时 OMS 尚未支持 MyCAT，所以采用 obbinlog 进行反向同步数据，然后通过 Canal 或 Flink 在正向切换完毕后，将数据反向同步到 MyCAT。MyCAT 会根据自身的分片规则，将数据反向同步回 MySQL 节点。

初尝 OceanBase，硬件成本降低 52%

由于快钱业务线众多，本次仅通过将账户、风控、小微交易、监控、部分大数据业务迁移至 OceanBase。从 MyCAT 迁移到 OceanBase 后，业务的降本和增效显著，硬件成本降低了 52%。

此外，高可用、资源利用、运维等方面均得到改善：

• 我们曾经对集群中任意一个节点进行搬迁升级，业务均无影响；

• 底层硬件资源除了存储空间，均可做到资源独立，这样就能根据业务的需求进行灵活的扩容和缩容。

• OceanBase 运维平台 OCP 功能强大，不但拥有常规功能如图表监控、badsql 监控、短信发送等，还可以通过动态调整租户、集群资源的方式救急。如果出现突发流量或 badsql 导致的问题时，可以使用 SQL 限流功能。如果需要水平扩容，对应用毫无影响，甚至还有完美的最终链路追踪功能。

• 在平时 DB 上线方面。OceanBase 的在线 DDL 比 MySQL 强大太多。基本做到了业务无感知。

目前 OceanBase 支撑快钱业务系统稳定运行，未出现性能抖动。未来，其可靠性和性能得到进一步验证后，我们考虑将继续探索 OceanBase 的更多特性，逐步将业务系统数据库迁移到 OceanBase。

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

https://github.com/oceanbase/oceanbase