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

[wxVIP]

内容场景：
原来老的服务 A 与新的服务 B ，B 是复刻 A 的数据库所有内容，但 A 服务写入的数据是异步的。
现在需要将原本指向使用 A 服务的数据输入都指向新的 B 服务，如何保证在切换服务的过程中 B 服务不会丢失这段时间内 A 服务异步输入的数据呢（ B 服务开始不断接收新数据）？

A 服务使用 MySQL ，B 服务使用 Pg

[mercury233]

要求高就停服，要求低就后补

[perfectlife]

这种稳妥就是允许切换时候停服务后检查一下数据

[picone]

1. 双写 /双读，根据业务进行取舍。比如 B 读 Pg + MySQL ，或者 A 读 Pg+MySQL ，又或者两个服务都写一遍两个库。
2. 如果不是太重要的业务能接受一段时间不一致，可以用 binlog 同步去 pg
3. 网关对用户进行分流，新用户都在 B 服务，但是不太好回滚。

[shineshane]

不停服我感觉没有什么完美的方案，低活跃时间段冷切换吧。

[wxVIP]

@mercury233 停服是不可能停的

[wxVIP]

@perfectlife
@shineshane

业务量较大，肯定是不允许停服的

[wxVIP]

@picone 目前考虑的方案也是双写，但是还是有问题，A 服务的数据是异步写入的，切换过程后异步队列中可能还存在数据，这种常驻内存的代码还是执行原来写 A 服务的，所以这段代码就会丢失不会被双写入 B 服务

[shineshane]

@wuxi889 #6 没有低活跃时间段么？提前发个维护公告感觉也不是不行，夜间加班切换下。

[picone]

@wuxi889 #7 我没有理解，一条数据要不就是让 A 处理，要不就是让 B 处理，无论是哪个服务处理都得写两个数据库。
其实你把新服务当成是能灰度发布就行了，会存在中间态。

[shineshane]

@picone 我有个疑问，就是双写双读的时候要发布新版本才可以做到，那么如何保证热发布时两个数据库的状态一致呢？

[opengps]

热更新难度很大，里面很多细节，平滑过渡需要存在同时写的一个阶段。
偷懒的做法，就是停机维护

[perfectlife]

@wuxi889 我其实还是想说没啥不能停的，停服比出事故再去急救简单多了，银行 /腾讯 /阿里 /字节 该停不还是停，停服嘛 不丢人

[kindjeff]

停机

[shineshane]

我的想法就是，不停机就是在找不自在，所有的方案都不完美，都是在拆东补西，用不在意的东西换在意的东西。

[picone]

@shineshane #10 如果讲强一致的话，那问题就复杂了，回滚之类的。看业务场景，我们之前的场景只需要保证数据能写入就行，所以没所谓。
就像你所说的，所有方案都不完美哈哈。其实只要适合业务就行了，会有一定的容忍度。

[LifStge]

热更也不是不行 但是很麻烦 要处理好所有差异的细节 很容易出问题
同时跑 然后热更一个中间层做兼容 能迁新就走新 然后等迁移完了 旧的没有使用的了 再热更 把兼容层下了

[julyclyde]

@wuxi889 真别太看得起自己的业务，说什么不能停机之类的
真正严肃的其实都停过，只是外人看不出来而已

[killva4624]

别的前面大佬们都说过了，做好要回切旧服务时候的预案。