百亿卡券数据架构升级：OceanBase单库双擎实践与踩坑实录

会员日大促结束当晚我盯着监控面板上的数据库CPU曲线没敢合眼。卡券系统的核心库在峰值时段CPU已经顶到80%以上磁盘IO等待时不时跳红这还是在提前做了批量发券削峰之后。运营同学一个“全员领券”的运营位就能让券表在几秒内涌入上千万次写入。这套承载了百亿级卡券数据的系统已经到了必须动大手术的临界点。最终我们从OceanBase方案里找到了一条“单库双擎”的升级路径这篇文章想把这次架构升级的来龙去脉、落地步骤和踩坑过程完整记录下来给同样被海量数据压着走的团队一个参考。这篇内容适合谁看如果你的业务也面临数据量几十亿起、写入和查询都极高并发、又要保证强一致性的状况或者你正在分库分表和分布式数据库之间犹豫这篇文章应该能帮你少走不少弯路。1. 卡券系统被百亿数据拖垮之前我们看到了什么1.1 卡券业务是一个被低估的“高并发怪物”很多人觉得卡券系统无非就是发券、查券、核销几个接口复杂度远低于订单交易系统。实际情况完全不是这样。卡券业务的负载画像非常特殊它有四个同时叠加的特征任何一个单独拿出来都很考验架构。第一写入量巨大。每次运营活动都是批量发券动辄千万级甚至亿级。用户领券、兑换码兑换、任务奖励发券每条记录都是一次独立写入。我们的券记录表在常态下每天新增几千万行大促期间单日新增量能冲到十亿级别累计历史数据早就过了百亿。第二状态变化极其频繁。一张券从生成到最终核销要经历未使用、已锁定、已核销、已过期、已作废等多种状态每次状态流转都是一次UPDATE。这意味着同一行数据会被反复修改行锁竞争和Undo膨胀在老架构里非常要命。第三金额敏感一致性要求极高。卡券余额、满减金额、折扣比例这些字段直接关联资金结算。用户在前台看到券可用后台就必须保证这个状态是准确且唯一的不能出现同一张券被两个订单同时核销的情况。第四流量突发性极强。运营活动一旦上线流量曲线不是慢慢爬坡而是直接垂直拉升。几秒钟内同一张券模板被几百万人同时领取是常态这就形成了典型的写热点。用一句话概括卡券系统是一个高频写、高频改、高频读、且时时有峰值突刺的业务对存储层的压力是全维度的。1.2 分库分表方案暴露出的四个结构性缺陷我们之前用的是MySQL分库分表的经典方案64个库、4096张表前面挂Redis缓存和MQ削峰。这套方案撑过了很长一段时间但数据量过了百亿之后四个问题越来越扎眼。第一个是跨分片事务。核销一张券往往涉及两个动作更新券状态为已核销、给用户账户增加可用余额。这两张表如果落在不同的分片里就必然涉及分布式事务。我们早期用本地消息表和MQ做最终一致性但这套方案有两个痛点一是链路长排查问题困难二是对账异常多经常要人工介入处理“状态已更新但余额没到账”这类问题。用户投诉一次客服和研发都要遭殃。第二个是热点无法根治。4096张表看起来分散了压力但同一张热门券模板对应的记录总归落在一个固定分片上。大促期间这个分片的数据库节点CPU被打满旁边的节点却闲着。分库分表只能按既定维度散数据完全没法应对这种单点突刺。第三个是扩容代价太大。从32库扩到64库的时候我们就吃过一次苦头要停读写、跑迁移脚本、做全量校验前后折腾了一个多月。扩完之后还要调整路由配置稍微有点疏漏就是线上事故。想想后面可能还要再扩一次整个团队都很抗拒。第四个是查询和分析能力被分片锁死。运营要拉“某个活动发了多少券、用掉多少、过期多少”这样的报表在分库分表架构下就是一个灾难。要么汇总到大数据平台做离线计算要么逐库逐表跑查询再聚合哪个都慢。实时运营决策根本无从谈起。这些缺陷靠加缓存、加机器只能缓解不能解决。我们需要的是一套能把百亿级数据装进一个逻辑库、同时又能扛住高并发事务和海量查询的存储方案。1.3 选型OceanBase的触发点不是因为它“网红”而是因为一个具体诉求前期调研时我们对比了好几类方案。继续扩分库分表不在考虑范围内原因上面说过。上NewSQL分布式数据库是方向但可选产品就那么几个。为什么最后选了OceanBase核心触发点有三个。第一个是它天然支持“单库”形态。这里的“单库”不是指单机而是指从业务视角看百亿行数据就是一个逻辑库、一套表结构、标准SQL不需要业务代码感知分片路由。分库分表时代刻在代码里的路由规则、分片键传递、跨分片查询兼容这些脏活累活全部可以扔掉。第二个是它具备“双擎”能力。简单说就是同一个数据库里既有一台擅长处理事务的行存引擎又有一台擅长跑分析和批量查询的列存引擎。两套引擎共享同一份数据上层SQL由优化器自动决定走哪套引擎执行。这一点后面我会展开讲它正好同时命中了卡券业务的OLTP和OLAP两类负载。第三个自然是稳定性。OceanBase在金融行业跑了很多年Paxos多副本协议、RPO0、RTO控制在秒级这些硬指标对我们这种金额敏感型业务来说是刚需。拿分库分表时代“主从切换可能丢数据”的问题做对比差距是代际的。2. “单库双擎”拆开看一个库两台发动机2.1 先理清概念单库和双擎分别解决什么问题“单库双擎”这个词第一次听到的时候很容易误以为是什么炫技概念拆开来看其实非常实在。“单库”解决的是数据规模和数据分布的问题。百亿行数据以前要塞进几千张物理分表里现在全部放进一个逻辑库。OceanBase内部会自动把表按分区打散到多台机器上但应用和数据库之间只隔了一层标准SQL完全感知不到物理分布。这对业务开发团队的意义非常大不需要再为分库分表写任何特殊代码SQL怎么写都行跨分区查询也能跑只是性能有差异而已。“双擎”解决的是负载类型混合的问题。卡券系统的读和写特征差异极大。事务型操作发券、核销、状态流转要求延迟低、强一致一条SQL影响的行数很少分析型操作对账、报表、批量筛查要求吞吐大、扫描范围广一条SQL可能扫上亿行。这两种负载放在同一个引擎里天然会互相打架。OceanBase的“双擎”做法是在同一个集群里同时部署行存引擎和列存引擎业务表可以建行存索引也可以建列存索引。优化器拿到SQL后自动判断点查和小范围更新走行存大范围聚合分析走列存。对业务来说这是透明的但对DBA和架构师来说相当于在同一个库内部实现了一套负载分流机制。我们戏称它是“一车双引擎”的混动架构只不过这台车不需要司机手动切换动力来源。2.2 OceanBase的底层能力为什么能撑起“双擎”这套架构能落地的关键在于OceanBase几个底层技术点的组合。第一个是LSM-Tree存储结构。传统MySQL的B树在大量随机写入时会产生严重的磁盘IO竞争而LSM-Tree把随机写转化为顺序写配合内存中的MemStore缓冲写入性能天然有优势。我们实测下来OceanBase的批量写入吞吐比同等配置的MySQL分片集群高出一个量级这对于单日十亿级券写入的场景来说属于“需求对上号了”。第二个是Paxos多副本协议。每一行数据在多个副本之间实时同步主副本故障时系统自动选主RPO为0RTO控制在秒级。这套能力解决了一个分库分表时代最头疼的问题——主从切换时的数据一致性。卡券系统出问题可以接受短暂不可用但绝对不能接受已经核销的券数据回滚或者丢失。第三个是行列混合存储。一张券流水表行存索引扛住前台“查询我的券包”这种按user_id定位的点查列存索引扛住运营后台“统计某天所有渠道的发券和核销情况”这种大范围扫描。两套存储共用同一份日志和同一套事务机制不需要像以前那样把数据导出到分析型数据库天然不存在同步延迟和口径不一致问题。第四个是资源隔离能力。在同一个OceanBase租户里可以通过配置资源组把OLTP和OLAP两类负载做物理级别的CPU和内存隔离。这意味着即使有人在后台跑一个超大的对账查询也不会把前台核销事务拖垮。在分库分表时代这是完全做不到的——一次慢查询直接拖垮整个分片节点的例子我们见过太多次。2.3 为什么不是简单地“MySQL加一个列存索引”有人可能会问现在不少数据库都支持列存索引OceanBase这个“双擎”有什么特殊这里有一个容易被忽略的差别。普通MySQL上加列存索引底层还是一套存储引擎事务、日志、锁机制都是行存模式列存索引只是加快读但写入时的维护代价依然高而且列存和行存之间的一致性依赖外部同步。OceanBase的“双擎”是内核层面两条完整的执行路径事务引擎负责行存路径分析引擎负责列存路径两者共享底层分布式日志和事务协调器数据的一致性由数据库内建机制保障不是靠应用层双写。对我们的直接好处是对账和报表可以直接读在线库不需要再ETL到独立分析系统。运营同学要的数据过去要等T1离线跑数现在实时就能查。这个体验上的飞跃在我们内部推广OceanBase落地时比任何性能指标都有说服力。3. 升级落地路径SQL打标、数据迁移、灰度切换三步走3.1 第一步给所有存量SQL做一次“负载画像”架构升级最大的风险不是技术而是对现有系统的理解不够透彻。我们做的第一件事不是搭环境而是把所有访问卡券库的SQL全部捞出来逐条打标分类。打标的维度有三个SQL类型SELECT/INSERT/UPDATE/复合事务、访问模式点查/范围查/聚合查询/大事务、流量等级日常QPS、峰值QPS、大促倍率。这个工作持续了两周产出了一份完整的SQL台账。目的很明确搞清楚哪些SQL属于OLTP路径需要走行存引擎哪些SQL属于OLAP路径可以改造走列存引擎哪些SQL是“坏SQL”得在大促前优化掉。这一步的价值在后续迁移中体现得非常充分。因为我们提前知道了线上有几十条聚合类SQL会全表扫所以在建列存索引时能精准覆盖也因为有大致QPS评估切流量的时候能分阶段控制压测压力。提示SQL打标工作一定要让核心业务的开发参与进来不能只靠DBA。很多SQL是历史遗留的连写的开发自己都不记得其业务含义只有追着业务线一条条确认后面的改造才不会有盲区。3.2 第二步存量数据迁移核心是“接力”而非“搬运”百亿级数据从MySQL迁到OceanBase看起来是个ETL问题实际上是个工程问题。我们用的是“全量增量”接力迁移方案。第一步是全量迁移。通过数据迁移工具把MySQL里的历史数据按主键分批读出来写入OceanBase。这一步看着简单但有一个参数要特别注意分批大小和并行度。之前我们同步其他业务线时用默认参数结果源库的IO被打满业务侧出现明显的查询变慢。后来我们把单批大小控制在5000行、并行度限制在源库CPU的20%以内才算平稳。第二步是增量同步。全量迁完后MySQL上还有持续写入的新数据。我们在应用层加了双写逻辑新写入同时落MySQL和OceanBase同时用同步工具追binlog补增量。这里周期内需要反复校验两边数据的一致性我们专门写了一套按主键范围分段的checksum比对脚本每天跑一次确保数据缺口逐步收敛。第三步是切换窗口。当增量断点在分钟级别内、校验误差为零时进入正式切换窗口。切换当天先停写把最后的增量补完然后做一次全量校验再打开OceanBase的写入开关同时把读流量切过去。整个过程耗时约30分钟对于卡券系统这样一个内部系统来说这个停机窗口在可接受范围内。3.3 第三步灰度切换不是技术问题是风险管理问题数据迁完不等于上线成功。我们把流量切换分了四个阶段内部验证、5%灰度、20%灰度、全量。内部验证阶段最容易被忽略但恰恰最重要。我们没有直接切业务流量而是让QA团队和核心开发用自己的真实账号走了一遍完整业务链路领券、查看券包、核销、退券、过期清理。系统在真实数据上跑通并不代表业务逻辑没问题只有真实动账才能发现并发场景下的边界情况。5%灰度阶段用user_id哈希取模圈了一批种子用户持续观察了48小时。这里看的核心指标不是接口成功率而是数据一致性核销流水、余额变动、券状态流转有没有出现异常。我们专门做了一个对账任务每15分钟比对一次OceanBase和离线数仓的结果集一旦出现偏差立即熔断回切。20%灰度阶段开始观察性能指标。重点看两个一是行存引擎的P95延迟在高峰期的表现二是列存引擎在跑批任务时对OLTP负载有没有资源抢占。直到这两个指标都稳定才放量到100%。提示回滚预案不是写在文档里就完了一定要提前演练一次。我们在灰度阶段真的触发过一次回切因为发现某个对账SQL走列存索引后结果延迟偏高。事后复盘发现问题不在数据准确性而是对账任务和业务高峰撞在了一起。如果没有提前演练过回切那次线上问题处理时间至少要翻一倍。3.4 切换后的SQL治理让每条SQL走对引擎切到OceanBase不意味着大功告成SQL执行计划的调优才刚开始。传统MySQL环境下很多查询依赖索引和表结构设计OceanBase环境下执行计划的选择更依赖统计信息和引擎感知。我们遇到的一个典型问题是一张券流水表同时建有行存索引和列存索引优化器偶尔会把一个点查SQL错误地路由到列存索引上导致延迟从2毫秒涨到200毫秒。解决办法是给核心SQL绑定执行计划强制指定走行存索引而对那些需要全表聚合的报表SQL反过来强制绑定列存索引。另外就是分区键选择。OceanBase推荐表按分区维度组织数据分区键和查询条件的匹配程度直接决定SQL是走单分区扫描还是全分区扫描。我们把券流水表的主分区键定为user_id因为前台几乎所有的点查都是按用户维度发起的把券模板维度的统计需求做成列存索引用单独的模板ID做二级分区这样后台报表扫描可以按模板快速裁剪分区大幅减少扫描量。4. 升级前后的账本延迟数据、资源成本、运维人效4.1 性能指标写入吞吐和查询延迟的变化先看一组我们线上观察到的量级对比。这套系统在MySQL分库分表阶段日增数据量在亿级时核心库的CPU常态维持在60%~70%大促峰值直接飚到95%以上我们经常在大促期间手动限流和降级。迁移到OceanBase之后同样的业务量级峰值CPU稳定在40%以内且因为写入模型从BTree随机写变成了LSM-Tree顺序写磁盘IO压力也大幅下降。查询延迟的变化更直观。用户“我的券包”列表查询分库分表时代P95在80毫秒左右OceanBase行存点查P95稳定在5毫秒以内。运营后台的券核销趋势报表以前走离线数仓要等第二天才能看到现在通过列存索引直接查在线库100亿行数据上的聚合查询秒级返回。这个差距带来的不仅是体验提升还直接改变了运营的工作方式——从“第二天看数据”变成了“现在就能看数据”。指标分库分表阶段OceanBase单库双擎变化日增券数据量亿级十亿级提升一个量级核心库峰值CPU95%40%以内大幅下降用户券包查询P9580ms5ms延迟降低93%大促写入吞吐需限流降级无需限流容量弹性提升运营报表时效T1实时秒级实时化4.2 成本账机器少了存储省了人放出来了成本方面的变化是一个意外之喜。分库分表时代为了分散压力我们准备了大量的高配物理机存储利用率其实很低——每台机器上都有一大堆从库副本在空转只为应付极端流量。OceanBase的Paxos多副本机制虽然也要存3副本但同一套集群可以被多个业务共享整体机器规模反而比分库分表时代减少了约40%。存储压缩也带来了直接收益。OceanBase的压缩算法在券流水这类字符串比例高的数据上表现非常好我们线上观察到的压缩比在3:1到4:1之间。100亿行历史数据迁移过来之后物理存储反而比原来小了近三分之二。更关键的收益是运维人效。分库分表时代DBA团队最怕两件事扩容和数据搬迁。一次扩容从准备到完成需要几周时间中间还要协调业务停机窗口。现在底层集群扩容是自动的数据均衡上层业务完全无感知DBA从“搬家工”变成了“性能调优师”。团队里原来专职维护分库分表中间件的同学现在转去做数据治理和SQL审核价值感完全不同。4.3 大促峰值下的真实表现一次零故障的会员日最能检验架构成色的还是大促。我们升级后的第一次会员日大促当天发券总量比上一年同期增长了30%但数据库侧没有一个告警核心接口成功率100%。这次大促我们做了什么特别的准备工作首先让OceanBase提前一周做了资源扩容把租户的CPU和内存配置临时调高其次把所有大促核心链路SQL的执行计划提前进行绑定避免执行计划在峰值期间发生意外变化另外专门为发券热点做了分区优化——把热门的券模板按批次拆分为多个逻辑子批次避免所有写入都怼到同一个分区上。这套“扩容预绑定热点拆分”的组合拳在大促期间几乎没给数据库添任何麻烦整个系统平稳得像日常一样。5. 这套架构踩过的坑比收获更值得看5.1 坑一分布式事务的边界禁用了但没完全禁用切到OceanBase之后我们一度以为分布式事务的问题已经彻底消失直到某次数据校验发现账实不一致。排查下来问题出在一个“看起来是单库事务、实际上是跨节点事务”的场景上。原因在于OceanBase虽然是逻辑单库但数据物理上分布在多个节点上。一个事务如果涉及多个分区OceanBase分布式事务框架其实也要做两阶段提交只是对业务透明而已。跨分区事务相比单分区事务延迟和失败率都会高一些但业务代码里根本感知不到这是透明带来的“隐藏风险”。我们的应对策略有两个。第一个是在业务设计上尽量把事务收敛到单分区比如领券和核销的操作按user_id维度设计表结构确保同一个用户的操作落在同一个分片上。第二个是加了一道静态检查工具在代码评审阶段自动识别可能产生跨分区事务的SQL提前人工干预。提示不要以为分布式数据库的“透明”是万能的。透明只是把复杂度从业务层转移到了数据库内核但性能差异依然存在。能用单分区事务解决的问题千万不要丢给分布式事务框架。5.2 坑二热点券写入倾斜单分区照样被打爆这是我们迁移后遇到的第一个性能事故。某次运营活动推了一张全网通用的“5元无门槛券”因为券模板ID只有一个所以所有写入都落在同一个分区上。OceanBase的单分区写入能力再强也有物理上限。当时那个分区的CPU直接拉满写入延迟涨了几十倍。解决方案说起来简单做起来需要业务配合把热点券模板拆成多个逻辑批次每个批次用不同的批次号做分区键。比如原来一个“5元券模板”拆成batch_01到batch_20二十个子模板应用层随机选择批次写入这样写入压力就被均匀分散到20个分区上。查询时按用户ID定位也能快速找到对应的券记录不受拆分影响。这类热点问题的共性规律是热点永远出现在“少数几个被大量并发访问的对象”上。架构升级只能提供分散写入的基础能力能不能真正把热点散开还得看业务表结构设计是否提前做了功课。5.3 坑三数据校验不能只做抽样必须全量增量双轨比对迁移过程中最怕的是数据不一致而校验数据的一致性本身也有坑。我们早期为了省时间采用抽样比对的方式随机抽取1%的数据做checksum校验。看起来很合理结果在某个分区上漏掉了一批数据。后来我们把校验策略改成了“全量增量”双轨全量校验每天跑一次通过分段checksum对每一个主键范围内的数据做完整比对虽然耗时长但能彻底兜底增量校验则在同步链路的前端实时比对binlog消费位点和目标库的写入情况确保迁移过程中任何一个时点两边数据都不会有不可控的偏差。这个组合式的校验方案让我们的心理压力小了很多。5.4 坑四列存索引不是万能加速器用错了比不用更慢在给运营报表提速时我们一度把所有大表都建上列存索引结果发现有些查询反而变慢了。深入排查后发现列存索引适合大范围扫描和聚合类查询但如果是高并发的小范围点查走列存反而因为跨行解析开销导致延迟更高。正确的姿势是先分析SQL的负载类型再决定是否建列存索引。我们后来定义了明确的规则——单次扫描行数超过百万级的查询才考虑列存而点查和小范围查询必须走行存。同时配合OceanBase的资源组隔离功能把列存查询限制在单独的CPU资源池里避免分析任务抢占事务任务的资源。6. 什么样的业务适合复制“单库双擎”什么不适合6.1 可复制的判断标准三条同时满足这次升级之后不少团队来问自己的业务是不是也应该往OceanBase这套架构上迁。根据我们的经验判断标准可以抽象成三条建议同时满足再动手。第一条数据量至少在几十亿级以上。如果业务数据只有几亿行传统MySQL主从架构加上合理的缓存设计完全够用没必要引入分布式数据库带来的运维复杂度。迁移是有成本的小数据量场景下的收益支撑不起这个成本。第二条业务同时存在高并发事务和海量数据分析诉求。只有偏读写一端的负载选型会更简单偏事务用传统关系型数据库偏分析用数据仓库。正是“两边都重”的场景才值得用“单库双擎”来同时承载减少数据搬运和多系统间的口径不一致。第三条团队有足够的数据库内核认知。不是说业务开发要懂内核而是核心架构和DBA团队需要对分布式事务、LSM-Tree、执行计划这些概念有基本理解。OceanBase这套架构解决了分库分表的物理限制但对使用者的要求从“会分库分表”变成了“懂引擎特性”门槛是迁移而非消失。6.2 不建议的场景和三种“别碰”反过来有三类场景我不建议硬上这套架构。第一种是业务模型极其简单的情况。比如只是几千亿行的日志流水没有事务、没有强一致性要求用对象存储加分析引擎更划算没必要上分布式数据库。第二种是团队没有专职DBA的情况。OceanBase的日常运维和调优比MySQL复杂需要有人能看懂集群状态、分析执行计划、调整资源规格。没有专职负责的人出了问题会很被动。第三种是对停机切换有苛刻要求的核心交易系统。虽然OceanBase本身支持在线迁移但应用层的切换操作总归需要一个观察期。如果业务一天都不能断、且不允许灰度迁移的风险和复杂度会成倍增加需要更精细的切换策略设计。6.3 最后再分享一个切换期间的小技巧切换期最容易忽略的是连接池的缓存问题。我们第一次灰度时切换数据库连接串后发现总有5%的请求还在连老库排查了半天发现是应用服务的连接池把老的连接缓存住了30分钟后才完全释放。后来我们在连接串变更时强制对应用服务做一轮分批重启确保所有连接都是新库的这个问题再也没有出现过。一个小细节但如果在切换高峰期踩中排查代价非常大。从分库分表升级到OceanBase“单库双擎”本质上是一次把手动管理数据库物理分布的模式升级为依靠分布式数据库内核能力自动管理数据分散、事务一致和负载分流的模式。我们这批人最大的感受是架构升级真正的价值不是省了几台机器、降了几个毫秒而是把团队从繁琐的分库分表维护中解放出来有了更多时间去做真正影响业务的事情。卡券业务只是第一个跑通这套架构的业务线我相信它会成为一个模板后面会有更多百亿级数据的系统走到这条路上来。