在马来西亚Touch n Go eWallet 早已不只是个扫码付款工具地铁、高速、停车、外卖、保险、助学贷款都能往里塞。TNG Digital 把支付交易核心的数据底座构建在 OceanBase 之上这个动作在东南亚金融科技圈讨论度很高。大家真正好奇的不是“OceanBase 行不行”而是“支付这种对一致性、可用性要求极为苛刻的场景为什么会选原生分布式数据库而不是继续用传统单机数据库配上分库分表中间件”。要回答这个问题得先把支付业务对数据底座的真实需求拆开看。1. 东南亚钱包业务的“数据底座”到底要扛住什么1.1 交易链路与数据库负载画像很多人把支付系统想成“余额扣一笔、流水记一笔”其实真实链路复杂得多。一次二维码付款从用户扫码开始要经过商户信息查询、用户账户状态校验、风控规则实时判断、额度与优惠计算、账户扣减、商户入账、交易流水落库还要往下游对账和通知系统发消息。这里面绝大部分操作都会打到数据库上而且是以“短小事务”为主的高频小查询。这样一个负载模型和一般互联网业务的“读多写少”完全不同它是典型的“读多写也多、写后还要立即读一致”。TNG Digital 覆盖的用户量级是千万级日常产生的交易笔数以千万计到了斋月、开斋节、开学季、双十二这类节点峰值会突然跳到日常的好几倍。地铁闸机的高峰就是早上 8 点到 9 点那一个小时所有人都卡在扫码过闸后台的数据库请求量会瞬间拉满。如果数据底座扛不住这种脉冲式流量用户看到的就是付款转圈、支付失败、客服涌入任何一家支付公司都不敢拿这个开玩笑。传统架构在数据库层通常是“单主多备”所有写入都集中在主库备库只负责读和容灾。业务量大了以后主库单点瓶颈一旦出现就得人工拆库、拆表把不同业务分到不同实例。拆完以后跨实例的数据查询、分布式事务、全局唯一主键全变成研发团队的噩梦。支付业务每天要大量做资金核对跨实例拆库会让对账逻辑变得极其复杂。这就是为什么“数据底座”这个词在支付场景不是抽象概念它直接决定了你能支撑多大规模的交易、能不能在峰值时快速扩容、出故障时能不能在几分钟内恢复。1.2 资金安全对数据库的事务与一致性要求支付和普通内容系统最大的区别是每一笔交易都涉及钱。用户账户余额扣减、商户账户入账、平台手续费收入这些必须在一个事务范围内保持一致。如果数据库只保证“大多数请求成功”而某个节点的写操作在主备切换时丢失就会造成用户钱扣了但订单没生成、或者商户收到重复入账这类严重后果。传统主备架构的隐患恰恰在这里主库把事务提交给备库之后先返回客户端成功主库恰好宕机备库没有完全同步这种极端情况下会有数据丢失。为了规避风险要么把同步模式改成强同步牺牲一点可用性要么依赖中间件做复杂补偿要么就寄希望于运维人员处理主备切换时足够快。但金融支付场景不会给你“概率低”这种安慰监管、审计、对账机制都要求资金流水可追溯、不可丢、不可重复。分布式数据库解决这个问题用的是多数派协议。OceanBase 每个分区默认保存多份副本写入时只要多数派副本都记录了事务日志客户端才会收到提交成功。少数派节点故障不会影响数据安全也不用像传统主备那样等待备机追上进度。这种机制从架构上把“丢数据”的概率降到了可以忽略的水平。支付团队引入分布式数据库追求的第一件事绝不是性能而是这种确定的、可证明的数据安全边界。1.3 大促与突发流量弹性扩容不再是可选东南亚市场有个特点节日大促明显而且出行高峰非常集中。开斋节前夕整个城市的人都在赶路高速收费站、地铁、商超、线上电商全部叠加交易洪峰几乎是同时压过来的。如果数据库容量按峰值去预留一年里有 300 多天是浪费按均值去规划真到峰值又必然撑爆。传统架构要扩容通常要经历“建立新实例、数据全量同步、切换流量、再压测”这一整套流程少则几天多则几周。支付业务并发峰值是小时级的流量起来了再扩容根本来不及。OceanBase 这类原生分布式数据库提供的是在线水平扩展能力业务增长需要更大容量时往集群里加机器节点数据会按照一定策略自动重新分布不要求应用层感知每个数据分片在哪里。对业务团队来说扩容不再是一台台去操作实例而是变成资源规划层面的工作。弹性扩容的意义对数据底座不只是“能承载更大的量”更重要的是“给研发团队吃了一颗定心丸”。没有这颗定心丸每次大促前都要做极限压测、反复限流降级、提前把边缘功能砍掉这种工作是纯消耗并不带来业务价值。2. OceanBase 为什么能被 TNG Digital 选中架构匹配度拆解2.1 原生分布式架构与 MySQL 生态的平衡市面上标称“分布式数据库”的产品很多但不少实际上是“分库分表中间件 单机数据库”的组合SQL 解析、路由分发、结果聚合全在这一层处理底层还是一个个独立实例。应用要感知分片键跨分片事务还得依赖全局事务管理器运维中间件本身又是一件繁重的活。OceanBase 的架构是另一条路线它是一套自研的分布式数据库内核表数据在创建时就可以定义分区规则SQL 层会把查询自动拆到多个节点并行执行应用连接的是同一个数据库入口。从开发者视角看它更像一个“普通的、能水平扩展的数据库”而不是“一堆数据库拼起来的中间件”。这种透明性对支付研发团队极有价值因为业务代码不需要为了数据库拆分而设计特殊路由事务也能按普通 SQL 的方式去写。更关键的是它在生态兼容上做得比较聪明。OceanBase 支持 MySQL 模式兼容大量 MySQL 语法与协议开发团队用 MySQL JDBC 驱动用 DBeaver 这类常见数据库工具就能直接连接和管理。这意味着把原有应用迁到 OceanBaseSQL 改动量通常比想象中少。对 TNG Digital 这种体量的团队不可能让几十上百个研发花几个月重写数据访问层兼容性直接决定了迁移成本能不能接受。2.2 高可用与故障切换RPO≈0 不是噱头支付系统最怕的不是慢而是不可用。哪怕是凌晨三点的停机维护也会影响 7×24 小时的跨境支付、外汇兑换、自动还款这类业务。过去使用单机数据库时高可用通常依赖主从复制和 VIP 漂移切换时间通常在几十秒到几分钟一旦原主库数据没完全同步丢数据几乎不可避免。OceanBase 的多副本机制从根本上改变了故障处理方式。每一笔事务提交时日志要同步到多数派副本才返回成功因此节点宕机后新的 leader 一定包含全部已提交事务的数据。配合自动故障切换业务可以在较短时间内恢复写入应用层几乎感觉不到底层的角色切换。RPO0 是一个被反复强调的能力但在支付数据底座里这是刚性需求而不是营销词汇。这种架构带来的另一个变化是日常运维的“心理负担”变轻了。以前我最怕接到告警说主库磁盘残留日志过多、主从延迟过大半夜要做主备切换。切换之前还要反复确认备库是否追平切完还要手动补偿。而在多副本强一致架构里少数派节点故障时系统会快速选出新 leader运维要处理的是把故障节点加回来、恢复副本而不是纠结数据有没有丢。2.3 HTAP 能力让支付分析不靠第二套系统支付场景除了交易事务还需要大量实时统计与风控分析比如实时监控每秒钟的交易成功率和失败原因、分析当前用户在地铁站的排队请求量、计算同一商户短时间内是否有异常交易。传统做法是业务库把 binlog 同步到分析型数据库再由数据团队做一套 ETL 任务。这个链路的问题在于延迟和成本分析看到的永远是几分钟甚至几小时前的数据还要设计一套同步任务的监控体系。OceanBase 的 HTAP 能力在于能够同时处理事务型负载和分析型负载。它采用 LSM-Tree 架构存储数据写入有较好的合并和压缩表现同时支持在列存引擎上跑分析查询。在支付场景里一部分查询可以下推到数据库的只读副本或列存副本里执行不需要把数据再搬到其他系统。TNG Digital 这样量级的公司每天的交易日志大到难以想象如果能省掉一部分 ETL 搬运对成本和实时性都是直接收益。当然HTAP 不代表“什么分析都能放进来”。团队仍然会有正式的数据仓库和 BI 平台但很多实时性要求高的查询可以在数据库内完成这相当于给数据团队多了一层更灵活的处理手段。3. 从 Oracle/MySQL 到 OceanBase迁移与批量导入的一线实操3.1 兼容性评估先用 DBeaver 连接 OceanBase 做快速验证无论 TNG Digital 是全新构建还是从原有系统迁移技术团队在数据底座选型前都会做一轮兼容性评估。把现有业务里的建表语句、典型查询、存储过程如果有的话放到新数据库上跑一遍这个验证过程如果太复杂团队就没法快速判断迁移的性价比。我用过的比较轻量级的验证方式就是用 DBeaver 连接 OceanBase。DBeaver 是很多 DBA 和研发已经熟悉的桌面客户端在新建连接时选择 MySQL 驱动填上 OceanBase 的连接地址和端口就能看到数据库实例里的对象、表数据、执行计划。相比装一堆新工具来转换业务这个动作几乎零学习成本。如果原系统用的是 Oracle 数据库OceanBase 的 Oracle 模式也提供了一部分兼容能力例如支持包、存储过程、序列等常用特性。但这里要格外谨慎兼容模式不等于 100% 兼容。真实项目里Oracle 到 OceanBase 往往需要先做一轮 SQL 治理把特殊语法、隐式转换、特有的函数和优化器行为重新规整一遍。我见过很多团队因为“听说兼容 Oracle”就乐观估计工作量结果在存储过程翻译上花了一个多月。所以第一步永远是把现有对象清单梳理出来用工具连接后逐个跑一遍按复杂度排优先级而不是先改代码。3.2 全量增量迁移的典型链路设计支付系统的迁移不允许“停机一天慢慢导数据”。典型做法是采用全量增量迁移的方式把停机窗口压缩到分钟级。规划结构迁移是最先要做的。先在新集群创建好数据库、表、索引调整分区键和分区策略让表结构与业务访问模式匹配。接下来做全量数据迁移这个过程可以在业务运行期间进行但要注意导出数据的一致性。最稳妥的办法是在源库做一个一致性快照然后从快照导出同时开启增量同步持续接收源库的变更日志。等到全量数据导入完成增量同步追平到同一时间点再进行应用切换。操作时我会特别关注数据校验不是只比对一下行数就完事。支付场景的数据量太大最有效的是做多层校验第一层比对总行数和关键表总和第二层抽样比对关键业务字段的校验和第三层是切换前跑一遍对账脚本检查用户余额和交易流水的借贷关系是否平衡。一个在 TNG Digital 这种支付场景里常见的坑是有些表有逻辑删除标记应用层查询会过滤但迁移时如果同步工具没有准确解析过滤条件会在新库产生大量“不该存在的数据”。这类问题只能通过深度的业务抽样校验来找纯靠行数对齐很难发现。增量同步阶段要密切监控同步延迟延迟一旦异常增大可能是目标库的分区或索引设计不合理也可能是同步任务并发太高造成锁等待。切换完成后不要立刻销毁原库保留至少一两个账期的双跑验证时间这类“后悔药”在金融场景绝对必要。3.3 数据批量导入的并发参数与常见坑除了搬迁历史数据支付团队在日常运维里经常遇到“批量导入”的场景比如把历史上某个月的账单做修正、把商家白名单批量导入、把对账差异数据重新灌入。很多人图省事直接用 DBeaver 打开 Excel 一条条插入数据量几百条没问题一旦是几十万上百万条传统图形化客户端就会变慢、内存占用暴涨而且执行到一半中断很麻烦。数据量达到一定规模时要改用批量导入工具。OceanBase 生态下常用工具链包括 DataX、官方迁移服务OMS以及一些适配 OB 的开源工具。使用 MySQL 协议的 DataX writer 连接 OceanBase 也能跑通核心是把批量大小、并发通道数、连接池大小调到一个合理区间。下面是一个我在项目中常用的 DataX 配置要点以 json 片段为例{ job: { content: [ { reader: { name: mysqlreader, parameter: { column: [*], splitPk: id, connection: [{ jdbcUrl: [jdbc:mysql://source_host:3306/payment], table: [txn_log] }] } }, writer: { name: mysqlwriter, parameter: { writeMode: insert, batchSize: 4096, preSql: [truncate table txn_log_staging], connection: [{ jdbcUrl: jdbc:mysql://oceanbase_host:2881/payment, table: [txn_log_staging] }] } } } ], setting: { speed: { channel: 4 } } } }注意这里的batchSize和channel要结合 OceanBase 所在机器的 CPU 与内存去调整。通道数不是越大越好我曾经把 channel 调到 32 去导一个几千万行的流水表结果目标库转储和 IO 压力陡增导入速率反而下降。比较稳妥的做法是从 2 到 4 个通道起步逐步加压观察数据库的 CPU 用量和合并触发频率找到一个吞吐的“甜点区”。还有几个常见坑值得注意一是大事务写太多会导致内存开销过高尽量控制每个批次的行数二是批量导入要保证幂等性重复执行不能产生重复流水所以要么使用临时表要么预先设计好唯一键和去重逻辑三是时区问题支付订单的时间字段如果跨时区批量写入前一定要统一成标准时区否则后续对账会莫名其妙地出现时间差。4. 支付核心场景落地事务模型、热点行与性能调优4.1 热点账户更新从行锁排队到批量合并支付系统有一个所有数据库都解决不了的物理限制同一行数据在同一时刻只能有一个事务修改它。特别典型的场景是热门商户的余额账户每笔交易都要更新这个账户的累计入账金额。高峰期成千上万笔交易同时撞向同一行行锁竞争会直接把数据库的吞吐拉下来。处理热点行问题的思路不能只依赖数据库参数更多是要在业务设计上做文章。我见过比较有效的做法是“先异步聚合、再批量落账”把交易明细先快速写入明细流水表商户账户的累计金额通过一个带缓冲的汇总任务批量更新。这样明细写入不会因为更新同一行账户而相互等待账户余额的更新频率从每秒上千次变成每秒几十次甚至更低。OceanBase 也能通过调整事务隔离级别、设置较小的锁等待时间来让系统更早暴露冲突但这只是保护机制不能根治热点。真正要做的是在应用层识别哪些字段是真正的热点然后拆分账户结构。比如把一个大账户拆成多个子账户每个子账户对应一部分商户订单再通过一个汇总视图把多个子账户余额合并成对外展示的总余额。这种设计在传统单机数据库里也能做但分布式数据库的优势在于拆分后的子账户可以分布在不同的节点上天然分散行锁压力。4.2 慢 SQL 治理与执行计划优化数据库迁到 OceanBase 以后最容易出现的问题是“原来跑得很快的 SQL 变慢了”。原因通常不是数据库内核差而是执行计划没走对索引或者 SQL 没有利用分区裁剪。很多支付团队在单机数据库上有很成熟的索引经验但到了分布式环境还要额外关心“这个查询会扫描多少分区”。排查慢 SQL 的第一步永远是看执行计划。OceanBase 提供了EXPLAIN语法可以通过客户端直接查看 SQL 的计划形状。我最常看到的慢查询场景是订单表按用户维度分区但某个查询条件只带了“创建时间”范围不带用户 ID那么执行计划会扫描用户的所有分区。如果你用 DBeaver 执行一条查询发现耗时不稳定先从计划里看有没有PARTITION: ALL之类的全分区扫描提示。这类问题的解法有几个层次。最简单的方案是给查询条件建一个全局索引让分布式数据库通过索引快速定位数据而不是扫描全部分区。另一个方案是重新设计分区键把“用户 ID 时间”组合成分区键让业务上最常见的查询都能天然落到少数分区。还有一种办法是把高频查询改成按天/按月分表的定时汇总表牺牲一点实时性换取查询速度。支付场景里开发人员写 SQL 时如果能养成“先看分区裁剪、再看索引选择”的习惯能少踩很多性能坑。4.3 分库分表架构的替代全局索引与分区裁剪过去很多团队用分库分表中间件比如 ShardingSphere、MyCAT把同一张订单表拆到多个物理库。应用代码里需要显式指定分片键多表查询、跨分片聚合都很痛苦而且中间件本身是一个新的复杂系统。如果数据底座换成 OceanBase就可以在应用无感知的情况下直接把表做成分区表让数据库引擎负责分区的路由。但这不意味着“分库分表思路”作废。分区键的选择依然是分布式数据库设计里最重要的一环。支付订单表我建议以“用户维度”和“时间维度”组合来设计分区比如PARTITION BY RANGE (created_at)配合二级分区或按user_id哈希分区这样既能让常见查询走裁剪又能控制单个分区的大小避免分区太大导致平衡性差。全局索引是另一个容易忽略的点。OceanBase 的分区表默认建的是本地索引每个分区索引只能索引本分区的数据。如果你需要按“商户 ID”查订单但订单表是按“用户 ID”分区的那么就必须建全局索引否则查询会扫描所有分区。全局索引本质上是一个独立的分区表会增加写入开销所以不是越多越好。支付团队在建表时就要把访问模式梳理清楚把核心查询路径用的索引建好而不是等上线后再补救。5. 换底座之后成本、运维与业务交付的转变5.1 资源利用率与存储成本一套数据库的多租户复用TNG Digital 的业务线不是只有 eWallet还有营销系统、商户管理、风控、客服工单等一大堆周边系统。如果每条业务线各建一套数据库集群资源利用率非常低有的系统 CPU 长期在 5% 以下有的系统一到月底就爆。OceanBase 的多租户架构可以在一个集群里划分多个租户每个租户有独立的资源规格同时共享底层服务器的 CPU、内存和磁盘。一个比较直观的比喻是以前每个业务团队自己租一整栋办公楼不管用不用都得付全额租金现在变成一栋楼里按楼层分区每个团队按实际使用面积分摊成本。TNG Digital 这类规模的公司可以很自然地把“生产支付核心”“商户后台”“营销系统”放到同一个集群的不同租户中通过资源隔离保证核心交易不受周边系统干扰。存储成本方面OceanBase 的 LSM-Tree 存储引擎在压缩和编码上有明显优势。支付流水表的特点是行结构比较规整、字段重复度高编码压缩的收益会很可观。数据量越多这种成本优势越大。很多团队上 OceanBase 以后发现同样大小的数据占用的存储比原来 MySQL 小很多这在云资源账单上是非常直接的收益。5.2 运维复杂度从“分库分表中间件”中解放出来使用传统分库分表架构的公司数据库层面往往要维护好几套组件MySQL 实例、高可用管理工具、分库分表中间件、数据同步管道、备份恢复机制。中间件的版本升级、路由配置变更、全局自增 ID 的调整每一项都能让 DBA 头疼半天。更麻烦的是中间件本身又变成了一个高可用瓶颈你得再为中间件做集群复杂度层层堆叠。切到 OceanBase 以后很多原来由中间件承担的职责被内化到数据库内核里。分区路由、分布式事务、全局一致性视图、多副本高可用这些能力在数据库内部就已经完成。对运维团队来说虽然要学习 observer 进程、Zone 概念、租户资源规格、转储/合并这些新东西但需要维护的组件种类大幅下降。过去 “拆一个库要改动几十个业务配置” 的场景也会明显减少因为数据扩容大多是线性加节点。这里也想说句公道话OceanBase 的运维门槛并不低。它毕竟是一套分布式系统安装部署、参数调优、故障定位都需要专业经验。如果团队没有接触过建议先在测试环境完整跑一遍或者使用云上的托管版本。金融机构通常有专门的 DBA 团队培训起来问题不大但一定不要低估学习成本。5.3 对业务迭代速度的隐性红利数据底座升级带来的收益通常不会直接体现在一个功能上线速度上而是体现在团队“敢不敢做更大的事”。以前数据层容量接近上限新业务上线前要先评估“这个表要不要拆库”“那个查询会不会把主库打挂”研发时间被大量消耗在与业务无关的数据库问题上。有了一个能水平扩展、具备高可用能力的数据底座业务团队可以更快地迭代。比如 TNG Digital 如果要快速上线一个针对新场景的支付产品只需要在数据库里建新表、定义好分区和索引应用层按普通数据库连接方式访问不用再纠结底层数据分布。这种看起来不显眼的“自由感”在竞争激烈的东南亚金融科技市场里其实是很大的竞争力。结尾一些来自实践的真实体会我在实际项目中用过 OceanBase 之后最大的感受是分布式数据库不是一个“装上就快”的银弹它是一个让你有机会把精力从“分库分表”转移到“业务数据模型设计”上的底座。支付场景里的数据一致性、高并发、弹性扩容靠的不是某一个 SQL 技巧而是整套架构从选型到落地都足够体系化。如果你也在考虑把支付或金融核心数据迁到 OceanBase我建议不要一开始就纠结性能指标先把自己的核心表结构、访问模式、一致性要求梳理清楚再用 DBeaver 连上去跑一遍真实 SQL让业务团队和数据库团队一起做兼容性评估。这个前期过程做得越细后面迁移踩的坑就越少。