写点什么

一次线上生产库的全流程切换完整方案

  • 2025-01-24
    北京
  • 本文字数:1442 字

    阅读完需:约 5 分钟

一、现状梳理

本篇介绍了一次数据库迁移的完整方案。 本次需要改造的系统为一个较为陈旧的技术栈系统,其中 MongoDB 作为核心数据存储中间件,承担着存储全部核心数据的重要任务。该系统目前的配置为 1 主 1 副本模式,涉及 1 个数据库和 2 张表,服务于 7 个不同的应用。尽管系统架构相对简单,但其在日常运营中发挥着不可或缺的作用。目前需要将 MongoDB 存储在其它介质中,如何能够保障在不影响线上使用的情况下,平滑切流到新库,是本文主要探讨的问题。

二、迁移方案

2.1 迁移节奏

整体节奏分为

1.梳理范围,因为系统内不仅有 mongo 还同时有 mysql 数据源,需要梳理出使用 mongo 的所有业务范围

2.确定好原有的数据,应该存储在哪个介质中,确定好存储标准,需要能够 cover 住原有的所有业务,包括读写性能

3.对原有数据结构的 DAO 层进行改造

4.需要对数据进行双写并进行数据迁移

5.R2 流量验证/测试回归/数据比对 进行验证

6.切量:放量节奏




2.2 代码改造/数据异构

采用装饰器模式,统一控制双写逻辑(主写,辅写),统一控制切量逻辑,下线逻辑, 抽取代码中原有的直接调用底层 mongodb API 的代码,将其不改业务逻辑的情况下迁移到 Dao 层。这样做的目的是为了后续做切流适配逻辑。不改逻辑及出入参的目的是为了避免对当前业务造成影响。

选用数据源的依据为

基于以上原则,我们选用 JImKV(京东自研中间件),Mysql 和 ES 作为 MongoDB 的替换的数据源,数据源切换 Dao 层的改造方式如下:




2.3 存量数据迁移

考虑整体的数据量并不大单表 300w,通过大数据离线表的方式效率并不高,通过代码更加的灵活,可以随时调整速度和范围存量数据分了两部分 1、已经审核通过,申请单不会在有任何变更,可以随时迁移,比对 2、申请单处于过程中的数据,数据随时会变更。凌晨迁移,打开双写




2.4 增量数据同步

创建申请单和更新不包含状态字段时的操作

先写 mongo 再写 mysql,以 mongo 写入成功为准,写 mysql 失败,mq 异步补偿





三、上线三板斧(灰度/监控/回滚)

本章节主要探讨在进行数据迁移和代码改造这些基础工作完成之后,如何保障上线没有线上问题,如何保障平滑切流和听写,工作主要聚焦于上线三板斧,可灰度,可回滚,可监控等方面,具体工作如下:

3.1 可监控(数据对比读逻辑)

增量数据比对

双写数据完成后发送 MQ,消息里面查询新库,老库的数据进行实时比对,不一致数据记录不一致字段,关键字业务报警,写入日志文件,导出分析

存量数据比对

遍历全量老库数据,与新库查出数据,转换成相同对象对比数据一致性,异常数据写入日志文件分析




3.2 可监控(对比读逻辑)

对比逻辑,引入 R2 流量回放对比,提高对比速度,




3.3 可灰度(灰度切量读)

读切流,按照供应商和采销白名单+百分比来切流




切流时,由于需要根据 pin 对流量分散,但是不在同一线程内,使用 threadlocal 对商户信息进行设置和读取




3.4 可回滚(灰度切量写)

写切流 分为四步

1.首先验证 写新库没问题 相当于对新加代码进行灰度 如果有问题 进行回切

2.当验证写新库没问题,需要补齐数据库数据

3.当数据补齐后 转换为主写新库

4.后续如果读写新库都没问题 可以彻底下线旧库存




四、总结

本文详细梳理了线上生产环境的全流程,包括迁移和切换的灰度方案对比。在数据源选型方面,根据实际业务需求选择合适的中间件是整个工作的基石。在代码改造和数据异构方面,选择恰当的设计模式和合理的架构方案是关键所在。存量数据迁移和增量数据同步是不可或缺的步骤。上线过程中,确保系统具备可监控、可回滚和可灰度的能力,是实现平滑切换的保障。欢迎各位同学与我交流探讨。


发布于: 刚刚阅读数: 5
用户头像

还未添加个人签名 2024-01-12 加入

京东零售那些事,有品、有调又有料的研发资讯,带你深入了解程序猿的生活和工作。

评论

发布
暂无评论
一次线上生产库的全流程切换完整方案_后端_京东零售技术_InfoQ写作社区