V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX 提问指南
wuxi889
V2EX  ›  问与答

[不懂就问] 新旧服务切换如何保证数据一致性

  •  
  •   wuxi889 · 2023-01-29 15:25:31 +08:00 · 1512 次点击
    这是一个创建于 693 天前的主题,其中的信息可能已经有所发展或是发生改变。
    内容场景:
    原来老的服务 A 与新的服务 B ,B 是复刻 A 的数据库所有内容,但 A 服务写入的数据是异步的。
    现在需要将原本指向使用 A 服务的数据输入都指向新的 B 服务,如何保证在切换服务的过程中 B 服务不会丢失这段时间内 A 服务异步输入的数据呢( B 服务开始不断接收新数据)?

    A 服务使用 MySQL ,B 服务使用 Pg
    18 条回复    2023-01-30 10:37:36 +08:00
    mercury233
        1
    mercury233  
       2023-01-29 15:31:24 +08:00
    要求高就停服,要求低就后补
    perfectlife
        2
    perfectlife  
       2023-01-29 15:31:32 +08:00
    这种稳妥就是允许切换时候停服务后检查一下数据
    picone
        3
    picone  
       2023-01-29 15:32:50 +08:00
    1. 双写 /双读,根据业务进行取舍。比如 B 读 Pg + MySQL ,或者 A 读 Pg+MySQL ,又或者两个服务都写一遍两个库。
    2. 如果不是太重要的业务能接受一段时间不一致,可以用 binlog 同步去 pg
    3. 网关对用户进行分流,新用户都在 B 服务,但是不太好回滚。
    shineshane
        4
    shineshane  
       2023-01-29 15:33:37 +08:00
    不停服我感觉没有什么完美的方案,低活跃时间段冷切换吧。
    wuxi889
        5
    wuxi889  
    OP
       2023-01-29 16:44:40 +08:00
    @mercury233 停服是不可能停的
    wuxi889
        6
    wuxi889  
    OP
       2023-01-29 16:45:16 +08:00
    @perfectlife
    @shineshane

    业务量较大,肯定是不允许停服的
    wuxi889
        7
    wuxi889  
    OP
       2023-01-29 16:47:03 +08:00
    @picone 目前考虑的方案也是双写,但是还是有问题,A 服务的数据是异步写入的,切换过程后异步队列中可能还存在数据,这种常驻内存的代码还是执行原来写 A 服务的,所以这段代码就会丢失不会被双写入 B 服务
    shineshane
        8
    shineshane  
       2023-01-29 17:24:42 +08:00
    @wuxi889 #6 没有低活跃时间段么?提前发个维护公告感觉也不是不行,夜间加班切换下。
    picone
        9
    picone  
       2023-01-29 17:24:57 +08:00
    @wuxi889 #7 我没有理解,一条数据要不就是让 A 处理,要不就是让 B 处理,无论是哪个服务处理都得写两个数据库。
    其实你把新服务当成是能灰度发布就行了,会存在中间态。
    shineshane
        10
    shineshane  
       2023-01-29 17:28:03 +08:00
    @picone 我有个疑问,就是双写双读的时候要发布新版本才可以做到,那么如何保证热发布时两个数据库的状态一致呢?
    opengps
        11
    opengps  
       2023-01-29 17:29:43 +08:00
    热更新难度很大,里面很多细节,平滑过渡需要存在同时写的一个阶段。
    偷懒的做法,就是停机维护
    perfectlife
        12
    perfectlife  
       2023-01-29 17:35:48 +08:00
    @wuxi889 我其实还是想说没啥不能停的,停服比出事故再去急救简单多了,银行 /腾讯 /阿里 /字节 该停不还是停,停服嘛 不丢人
    kindjeff
        13
    kindjeff  
       2023-01-29 17:37:01 +08:00
    停机
    shineshane
        14
    shineshane  
       2023-01-29 17:40:28 +08:00
    我的想法就是,不停机就是在找不自在,所有的方案都不完美,都是在拆东补西,用不在意的东西换在意的东西。
    picone
        15
    picone  
       2023-01-29 18:26:27 +08:00
    @shineshane #10 如果讲强一致的话,那问题就复杂了,回滚之类的。看业务场景,我们之前的场景只需要保证数据能写入就行,所以没所谓。
    就像你所说的,所有方案都不完美哈哈。其实只要适合业务就行了,会有一定的容忍度。
    LifStge
        16
    LifStge  
       2023-01-29 19:03:01 +08:00
    热更也不是不行 但是很麻烦 要处理好所有差异的细节 很容易出问题
    同时跑 然后热更一个中间层做兼容 能迁新就走新 然后等迁移完了 旧的没有使用的了 再热更 把兼容层下了
    julyclyde
        17
    julyclyde  
       2023-01-30 08:51:49 +08:00
    @wuxi889 真别太看得起自己的业务,说什么不能停机之类的
    真正严肃的其实都停过,只是外人看不出来而已
    killva4624
        18
    killva4624  
       2023-01-30 10:37:36 +08:00
    别的前面大佬们都说过了,做好要回切旧服务时候的预案。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1041 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 84ms · UTC 23:15 · PVG 07:15 · LAX 15:15 · JFK 18:15
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.