摘要：
爱奇艺卡券业务原采用 “MySQL 分库分表 + ES 异步同步” 架构，面临 TP/AP 分离导致的架构复杂、AP 查询分钟级延迟、数据一致性隐患等问题。如今借助 OceanBase 的 HTAP 能力，将 AP、TP 业务融合到一个数据库，在架构简化、成本控制与效率提升方面均取得了突破。
爱奇艺是国内知名的在线视频平台，每年都会推出上百部优质长视频内容，其中不乏如 2023 年现象级爆款《狂飙》这样的佳作。近两年，随着短视频、微剧的兴起，平台年处理视频内容数量级从上百部直接跃升至上万部。
每一部内容从立项、拍摄、生产、制作到上线播出，均需经过复杂流程，并依赖上百个业务模块协同支持。卡券业务是出于整个业务生态里面的中台位置，对上提供中台能力，如为创新型业务会员、云影院提供商业化变现和用户转化营销工具。
过去，卡券业务系统将 AP（分析处理）与 TP（事务处理）业务分开处理，架构复杂，需要较高的维护成本；如今，借助OceanBase 的 HTAP 能力，将 AP、TP 业务融合到一个数据库，在架构简化、成本控制与效率提升方面均取得了突破。
解构卡券业务的数据架构困境
卡券是爱奇艺核心的营销与促销工具，贯穿爱奇艺的会员购买、云影院观影等商业化变现全链路。其底层数据库的性能直接关乎用户体验与业务敏捷性。
例如，促销发券、会员领券等场景均需要业务系统提供高并发事务处理（TP）能力。而在运营侧，则需要实时统计和分析发券数量、会员领券等指标，以便评估活动效果、优化营销策略，这依赖于高效的数据分析（AP）能力。
过去，卡券业务系统采用的是“MySQL 分库分表+ES 异步同步”的复杂架构：分库分表的 MySQL 来承载 TP 业务，以应对高并发海量请求；Elasticsearch（ES）来完成统计分析等 AP 类业务。
“这个卡券业务的架构基本上能为业务需求提供足够的支撑。不过，我们并不满意，一直在寻找新的解决方案。”爱奇艺高级总监张冲表示。
其最重要的原因就在于系统架构过于复杂，虽能满足业务需求，但每一个节点都需要研发投入大量精力维护，顶峰的时候研发资源占比近 80%，严重挤占了业务创新资源。
具体而言，在 TP 业务方面，通过分库分表的 MySQL 集群支撑高并发交易，但实际日常资源利用率仅约 10%，资源冗余明显。在 AP 业务方面，ES 进行运营统计分析时的数据源自订阅多个 MySQL 实例的 binlog，经消息队列 RMQ 异步同步至 ES，链路冗长，存在分钟级延迟。并且 ES 的清理归档代价较高，Reindex 开销也比较大。
此外，数据的一致性与准确性面临挑战，在异步同步过程中，甚至出现过 UV（访客数量）超过页面点击的异常，统计准确率难以保障。
张冲坦言，对现有架构进行升级更深层的原因，源于对技术进步的持续追求。“我们希望技术上再往前走一走，要和互联网行业最先进的技术保持对齐。”
从“分库分表+ES”到“单库双擎”，爱奇艺 HTAP 架构升级实践
随着新技术趋势的出现，爱奇艺也开始寻找能够简化架构、支撑业务更好发展的新发展。数据库的升级是这次架构升级的关键。
对于新一代数据库，爱奇艺提出了明确的要求：
第一，必须是一款兼顾 TP、AP，具备 HTAP 能力的数据库产品，无需管 MQ，无需处理异构的数据，尽量减少对数据平台的依赖，以简化数据底座；
第二，总体成本可控，和现有架构相比成本不能上升，符合公司降本增效的目标；
第三，云中立，在遇到故障的时候可以实现云逃逸，且在不同的云上均可提供一致性的服务。
根据上述三个基本要求，经过对多款主流数据库产品的调研与测试，OB Cloud 一体化云数据库凭借其卓越的性能与高度契合的需求满足度，赢得了爱奇艺的青睐，并且在高并发、高可用、安全、数据治理、低成本等方面的技术积累，都被浓缩到 OB Cloud 一体化云数据库的产品中。
张冲表示：“OceanBase 不仅提供了真正的 HTAP 融合能力，其原生分布式架构还与我们的云原生战略高度契合。同时，OB Cloud 在百度云上开服也是一个重要契机，因为爱奇艺的系统平台就部署在百度云上。”
完成数据库选型之后，爱奇艺迅速开始了数据和架构升级的准备工作。
升级工作分为两个阶段：
AP 升级：将 ES 集群中的百亿文档升级至 OB Cloud 集群。通过双写、迁移历史数据、切读、停双写等步骤，不仅完成数据升级，还从业务层面进行了逻辑去冗余和简化。最终，资源成本下降 60%，运营查询类 SQL 基本在 1 秒内返回。
TP 升级：将 16 个物理机数据库从原生 MySQL 分库分表形态升级至 OB Cloud 集群。借助 OceanBase 的 OMS 同步工具，顺利完成海量数据同步与校验工作。最终，存储成本下降 80%，且系统具备弹性伸缩能力，无需为大促提前预备资源。
张冲表示，为了尽量减少对业务的干扰，保持业务稳定性，升级过程尽可能少地修改代码，他们采取了一些措施：
1. 汇聚到 OceanBase 的分区表、分区键与原来的分片逻辑一致，使得业务系统零改造切换；
2. 保持 AP 业务不变，仅修改数据源订阅，通过全兼容的 binlog 直接订阅到同租户的 AP 表。此时还是多份存储，但依靠高压缩比，整体存储成本没有上升；
3. 将 TP 业务的表异步修改为行列混存，不影响业务稳定性，同时运营统计只需简单修改库和表名即可快速上线。通过多副本读写分离，最终实现了单库双擎、支撑实时在线业务与数据分析的简洁架构。
化繁为简，打造卡券业务的现代化数据库底座
经过升级改造后，卡券业务系统架构变得非常简洁，只有基本的业务服务和数据中台的数据交互，不再需要维护额外的数据流服务，也无需担心存储不足等问题，归档清理的周期也相应延长，研发人员得以更加聚焦于业务需求的开发。
张冲表示，卡券业务系统架构升级带来了如下好处：
首先，链路极大简化。 去除了 MySQL 到 ES 的异步同步链路，消除了 ES 集群的运维与成本；张冲特别感慨此次架构的升级带来的简化，他表示“简单到只有计算、只有存储，简单到有点像互联网刚开始发展的那个阶段。”
其次，分析效率提升。 常规 AP 查询可直接在 OB Cloud 中完成，时间也从原来的准实时变成了实时，所有统计 SQL 的响应时间（RT）均小于 1 秒，性能大幅提升。而 BI 类需求以前需要数据中台部门支持，属于跨部门协作，最快也需数天；现在本部门内部就能完成，时间缩短为 2-3 天；
第三，存储成本显著节省。 借助 OceanBase 的高压缩能力，相比 MySQL 的存储成本下降了 80%，并且它可以弹性伸缩，不再需要提前为大促预备过量资源。
“相对于之前的架构，现在的架构非常简洁。这要得益于 OceanBase 把高并发、高可用、安全、数据治理、低成本等各种技术积累都浓缩到了这个数据库产品中。”张冲这样评价。
小结
张冲表示，未来爱奇艺计划将 OceanBase 的实践推广至更多在线交易型业务，如订单支付、会员中心等，并逐步探索其在 KV 存储、向量检索等场景的应用。
面对 AI 浪潮，张冲也提出了对未来数据库的期待：“知识图谱、AI 工作流等复杂场景，需要更智能的底层数据支撑。希望OceanBase 能在这些方向持续演进，成为企业智能化转型的数据基石。借助 OceanBase 技术的不断完善和应用场景的拓展，爱奇艺将在科技创新的道路上走得更远。”
欢迎访问 OceanBase 官网获取更多信息：https://www.oceanbase.com/