编者按： 在移动互联网时代，在线支付和移动支付已经成为大众的普通选择。尤其在国内，除支付宝和微信支付两大巨头外，还有许多第三方支付企业为商家和用户提供便捷的支付服务，如金融型支付企业银联商务、快钱；信用中介型支付企业拉卡拉、嘉联支付等。如何保证交易的正确性、实时性和安全性？这与技术架构底层的数据库服务息息相关。本文通过分享快钱公司的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 开源负责人老纪的公众号「老纪的技术唠嗑局」，会持续更新和 #数据库 、#AI 、#技术架构 相关的各种技术内容。欢迎感兴趣的朋友们关注！
「老纪的技术唠嗑局」不仅希望能持续给大家带来有价值的技术分享，也希望能和大家一起为开源社区贡献一份力量。如果你对 OceanBase 开源社区认可，点亮一颗小星星✨吧！你的每一个Star，都是我们努力的动力。