爱奇艺于2010年4月22日正式上线，推崇品质、青春、时尚的品牌理念如今已深入人心，网罗了全球广大的年轻用户，积极推动产品、技术、内容、营销等全方位创新。2018年3月29日，爱奇艺于纳斯达克上市，股票代码IQ。爱奇艺持续以用户为中心，以变应变，构建长 + 短的内容生态，已成功打造了包含长剧综、微剧、微综艺、动漫画、电影、游戏、小说、IP衍生品、线下娱乐等业务在内、连接人与服务的娱乐服务体系，引领视频网站商业模式的多元化发展。
01#
背景
随着爱奇艺平台业务的不断发展，积分体系已成为用户运营、会员激励及跨端联动的重要基础能力。目前积分系统服务于四大业务方：极速版、基线业务、国际业务与综合端业务。每个业务方下设多个业务线，每条业务线又可能关联多个“积分线”，用于承载不同场景下的用户积分数据与权益逻辑。系统中，一个用户可对应多个积分线，每条积分线对应一个独立的积分账户，整体结构呈现高度多样化与大规模并发特征。
从技术架构上看，当前系统采用双存储结构：
MySQL 用于存储用户积分总值数据，支撑积分加减、总值查询、交易记录与计数等核心操作；
MongoDB 用于存储积分明细数据，主要支持历史积分变动记录的查询与追溯。
然而，随着用户规模增长、积分线数量增加以及多业务线并发操作持续提升，原有架构面临一系列挑战：
MySQL在总值存储场景中已成为性能瓶颈，其单实例写入能力有限，横向扩展复杂，难以应对积分业务持续增长的高并发压力；
分离式存储架构引发一致性与维护难题，总值与明细分别存储于 MySQL 与 MongoDB，需要引入分布式事务机制或双写补偿逻辑，导致系统复杂度上升，数据一致性难以保障；
系统维护与演进成本高，开发、运维需对两个数据库体系分别管理、监控、扩容，割裂的数据架构不利于未来统一调度与资源整合。
为应对上述挑战，技术团队决定对积分存储架构进行重构，选择一个可水平扩展的存储引擎，实现积分总值与积分明细的统一存储。需要支持事务以及灵活的数据模型，同时还需要降低架构复杂度与运维成本，能为未来多业务线协同发展与高并发高可靠场景提供坚实的数据基础。
02#
存储架构选型
为了将原来分别使用 MySQL 存储“总值”、MongoDB 存储“明细”的分离架构，统一存储，使架构更简洁。同时解决现有积分系统在数据规模持续增长、业务线日趋复杂背景下所面临的存储瓶颈与运维挑战，技术团队对数据库架构进行了系统评估与选型，所选型的存储服务需具备一下能力：
扩展能力：支持水平扩展，实现无限横向扩展；
并发能力：支持高并发，适合频繁积分加减操作；
事务能力：对于积分总值 + 明细同步更新操作纳入事务处理，替代原来依赖 MySQL 事务机制的部分逻辑，保证积分操作的一致性；
冗灾能力：具备高可用、自动故障转移能力。支持跨机房部署、优先级主节点切换等能力；
建模能力：灵活的数据建模能力。
经过评估，最终决定将积分总值与积分明细统一迁移至7.0 版本的MongoDB服务上。该版本具备强大的扩展能力、灵活的数据模型与显著的性能优化，是面向高并发、高可用业务场景的理想选型。
为什么选择MongoDB
MongoDB 7.0 在此背景下展现出明显优势。其原生分片机制支持系统水平扩展，可灵活支撑亿级用户和多业务线并发访问需求。同时，MongoDB 的文档型存储模型天然适配积分业务多变的字段结构，便于不同业务线在不做表结构调整的前提下独立扩展。此外，MongoDB 7.0 强化了事务能力与一致性机制，支持多文档事务和可配置的写入确认策略，满足了积分加减、回滚等核心操作对数据一致性的高要求。
在运维方面，MongoDB提供了完善的监控、告警与自动运维能力，配合公有云的实例托管能力，可显著降低人工维护成本。配套的 Change Stream、Time Series、全文索引等能力，也为后续扩展用户行为分析、积分洞察等数据增值场景提供了基础。
通过数据库架构升级，积分系统在性能、扩展性、一致性与运维效率方面均可得到全面提升，同时实现了数据存储的统一化与架构的简化。预计该架构将为今后中长期的业务拓展和系统演进提供稳定、可靠、高弹性的支撑。
03#
数据迁移方案
我们对现有架构进行了两阶段的升级迁移：将积分明细与积分总值全面迁移至公有云7.0版本的MongoDB集群，以实现统一存储、简化架构和增强系统可扩展性。
完善迁移工具
在积分明细数据迁移阶段，数据库团队对开源mongoshake同步工具做了诸多优化改进，实现了将MongoDB 3.4版本中积分明细的全量及增量数据同步至云上MongoDB 7.0集群。
开源版mongoshake存在诸多限制：同步日志文件过大、同步监控与主流监控系统不兼容性、源端负载较高时增量追平效率低等问题。为确保积分明细数据迁移过程稳定高效，团队对mongoshake进行了以下改造：
重构日志系统：替换默认日志 SDK，采用主流的 Uber zapLog，提升日志性能与可读性；
过滤操作类型：支持按需过滤 CRUD 操作，支持数据归档的功能；
优化增量同步：对增量阶段的同步机制进行调优，显著降低追平延迟；
增加延迟监控：新增获取和消费 Oplog 的延迟指标，便于在监控大盘中直观展示同步延迟情况；
重构监控体系：将原本零散的接口级监控数据整合为 Prometheus 结构，支持通过 Grafana 快速出图，提升运维可观测性。
通过改造，有效提升了mongoshake在高负载场景下的稳定性与可观测性，保障了积分明细数据平滑迁移上云。
积分明细迁移
引入MongoDB 7.0，完成全量明细数据同步
新增MongoDB 7.0实例，通过MongoShake工具实现MongoDB 3.4到MongoDB 7.0的实时全量数据同步。此阶段，业务系统依然读写MySQL和MongoDB 3.4，MongoDB 7.0作为同步备份库。
切换明细数据读取数据源
业务系统将明细数据的读取操作切换至MongoDB 7.0，确保新库数据可用性和稳定性。
下游链路同步与兼容性调整
下游数据消费及同步链路同步切换至MongoDB 7.0。如遇兼容性问题（如大数据同步服务不支持MongoDB 7.0），需将同步作业调整为基于mongo-spark-connector的SparkJob实现。
切换明细数据写入新库，回收老库
业务系统将明细数据的写入操作切换至MongoDB 7.0，完成数据迁移。待确认无误后，申请回收MongoDB 3.4老库资源。
积分总值迁移
积分总值迁移涉及数据结构调整与同步流程重构。
在 MongoDB 中批量创建所需的积分线集合，同时配置索引与分片策略
通过 DBIO 工具订阅 MySQL binlog到消息系统，再将全量数据也发到消息系统
score-consumer消费实时消息，并在增量数据追上延迟时，达到最终一致性写入过程中，通过云配限流开关控制集群压力，并新增扩展字段 ext_info 用于存储线上用户的积分请求参数，通过在后续环节回放请求到新版API来验证逻辑正确性。
为确保数据一致性，sync 模块在STEP2回放写操作执行完毕后，对增量请求执行多重校验，包括明细实验表和明细对照表，新总值表和老总值表，新总值表和新明细表的校验，若有任意不一致则触发告警进入问题数据定位分析阶段，待问题修复后继续循环上述流程直至没有告警。
实时校验开启后，正式切流前，通过对全量总值新老库的校验，同步全量库不一致的数据，达到新老总值库数据100%完全一致的状态，正式进入切流流程。
在灰度切流阶段，基于配置中心灰度开关逐步切换 UID 尾号流量，遵循 1% → 10% → 20% → 50% → 100% 的节奏分批推进，最终完成流量切换。
04#
迁移进度
截至目前，综合端积分系统、极速版积分系统已完成全部迁移任务。整个迁移过程在保障数据一致性和业务连续性的前提下，顺利实现了 MySQL 到 MongoDB 的架构转型，为后续多业务线、跨区域、千万量级账户场景提供了良好的技术基础。
迁移收益
服务稳定性增强
迁移后，系统整体运行更加稳定，接口超时499错误码明显减少，接口成功率趋于稳定，毛刺波动现象基本消除。即便在促销活动高峰期，系统也能保持良好服务可用性。不过在接口调用链中，平均响应略有波动，主要由于采用了更严格的写一致性策略，写操作需获得大多数节点确认后方可返回。该波动仍处于业务可接受范围内，换来的则是数据强一致性的显著提升。
系统并发能力增强
通过引入MongoDB 7.0的分片架构，系统可实现水平扩展，应对高并发写入与多积分线并发访问等业务场景。集群整体写入吞吐能力提升明显，资源瓶颈从数据库转向应用层业务逻辑。原有 MySQL 在单表/单库高并发下出现的锁竞争与资源耗尽问题得到根本性缓解。
数据一致性增强
统一迁移至 MongoDB 后，极大简化了原本依赖分布式事务或异步补偿逻辑的实现复杂度。通过对写操作配置majority写入确认机制与延迟一致性比对校验，确保数据在主备节点间强一致传播，极大降低了因异步或双写不一致带来的数据风险。
开发维护效率增强
由原先“双数据库、双接口逻辑”的混合架构，统一切换为基于MongoDB的统一数据模型，开发侧仅需维护一套读写逻辑与数据结构，接口联调和问题排查成本大幅下降。同时MongoDB丰富的诊断工具也有效降低了运维难度。
整体来看，本次迁移不仅实现了技术架构的优化和数据一致性的增强，也显著提升了系统在性能、扩展性、稳定性与维护效率方面的综合能力，为爱奇艺积分业务的未来发展打下了坚实基础。
