index_new5.html
../../../zaker_core/zaker_tpl_static/wap/tpl_guoji1.html
![]()
本文分享了京东零售在进行数据库迁移时的完整方案，重点关注如何在不影响线上业务的情况下，平滑地将数据从旧数据库迁移到新数据库。文章详细介绍了迁移的各个环节，包括范围梳理、数据迁移、代码改造、上线准备以及灰度方案，旨在确保迁移过程的顺利进行，并提供可监控、可回滚和可灰度的保障措施。
✅ 迁移前的准备工作至关重要，包括梳理MongoDB的使用范围，确定数据存储介质和标准，以及改造DAO层以适应新数据源。
✅ 迁移方案采用了双写机制，同时写入新旧数据库，并进行数据比对，确保数据一致性。增量数据同步通过MQ异步补偿机制，保证数据完整性。
✅ 上线过程强调“三板斧”：可监控、可回滚和可灰度。通过数据对比、R2流量回放对比和灰度切流等手段，实现平滑切换，降低风险。
✅ 灰度方案涵盖读写切流，读切流基于供应商和采销白名单+百分比，写切流分为验证、数据补齐、主写新库和下线旧库四步。
京东零售 杨亚龙 2025-04-11 07:16 广东
详细梳理，完整呈现，包括迁移和切换的灰度方案对比。
本篇介绍了一次数据库迁移的完整方案。本次需要改造的系统为一个较为陈旧的技术栈系统，其中MongoDB作为核心数据存储中间件，承担着存储全部核心数据的重要任务。该系统目前的配置为1主1副本模式，涉及1个数据库和2张表，服务于7个不同的应用。尽管系统架构相对简单，但其在日常运营中发挥着不可或缺的作用。目前需要将MongoDB存储在其它介质中，如何能够保障在不影响线上使用的情况下，平滑切流到新库，是本文主要探讨的问题。
1）梳理范围，因为系统内不仅有mongo还同时有mysql数据源，需要梳理出使用mongo的所有业务范围2）确定好原有的数据，应该存储在哪个介质中，确定好存储标准，需要能够cover住原有的所有业务，包括读写性能采用装饰器模式，统一控制双写逻辑（主写，辅写），统一控制切量逻辑，下线逻辑，抽取代码中原有的直接调用底层mongodb API的代码，将其不改业务逻辑的情况下迁移到Dao层。这样做的目的是为了后续做切流适配逻辑。不改逻辑及出入参的目的是为了避免对当前业务造成影响。基于以上原则,我们选用JImKV(京东自研中间件)，Mysql和ES作为MongoDB的替换的数据源，数据源切换Dao层的改造方式如下:考虑整体的数据量并不大单表300w，通过大数据离线表的方式效率并不高，通过代码更加的灵活，可以随时调整速度和范围存量数据分了两部分1）已经审核通过，申请单不会在有任何变更，可以随时迁移，比对2）申请单处于过程中的数据，数据随时会变更。凌晨迁移，打开双写先写mongo再写mysql，以mongo写入成功为准，写mysql失败，mq异步补偿
本章节主要探讨在进行数据迁移和代码改造这些基础工作完成之后，如何保障上线没有线上问题，如何保障平滑切流和听写，工作主要聚焦于上线三板斧，可灰度，可回滚，可监控等方面，具体工作如下:双写数据完成后发送MQ，消息里面查询新库，老库的数据进行实时比对，不一致数据记录不一致字段，关键字业务报警，写入日志文件，导出分析遍历全量老库数据，与新库查出数据，转换成相同对象对比数据一致性，异常数据写入日志文件分析切流时，由于需要根据pin对流量分散，但是不在同一线程内，使用threadlocal对商户信息进行设置和读取1）首先验证 写新库没问题 相当于对新加代码进行灰度 如果有问题 进行回切
本文详细梳理了线上生产环境的全流程，包括迁移和切换的灰度方案对比。在数据源选型方面，根据实际业务需求选择合适的中间件是整个工作的基石。在代码改造和数据异构方面，选择恰当的设计模式和合理的架构方案是关键所在。存量数据迁移和增量数据同步是不可或缺的步骤。上线过程中，确保系统具备可监控、可回滚和可灰度的能力，是实现平滑切换的保障。
来源丨公众号：京东技术（ID：jingdongjishu）dbaplus社群欢迎广大技术人员投稿，投稿邮箱：editor@dbaplus.cn
阅读原文
跳转微信打开
