这是一个创建于 698 天前的主题，其中的信息可能已经有所发展或是发生改变。
内容场景：
原来老的服务 A 与新的服务 B ，B 是复刻 A 的数据库所有内容，但 A 服务写入的数据是异步的。
现在需要将原本指向使用 A 服务的数据输入都指向新的 B 服务，如何保证在切换服务的过程中 B 服务不会丢失这段时间内 A 服务异步输入的数据呢（ B 服务开始不断接收新数据）？
A 服务使用 MySQL ，B 服务使用 Pg
原来老的服务 A 与新的服务 B ，B 是复刻 A 的数据库所有内容，但 A 服务写入的数据是异步的。
现在需要将原本指向使用 A 服务的数据输入都指向新的 B 服务，如何保证在切换服务的过程中 B 服务不会丢失这段时间内 A 服务异步输入的数据呢（ B 服务开始不断接收新数据）？
A 服务使用 MySQL ，B 服务使用 Pg
 |
1
mercury233 2023-01-29 15:31:24 +08:00
要求高就停服，要求低就后补
|
 |
2
perfectlife 2023-01-29 15:31:32 +08:00
这种稳妥就是允许切换时候停服务后检查一下数据
|
 |
3
picone 2023-01-29 15:32:50 +08:00
1. 双写 /双读，根据业务进行取舍。比如 B 读 Pg + MySQL ，或者 A 读 Pg+MySQL ，又或者两个服务都写一遍两个库。
2. 如果不是太重要的业务能接受一段时间不一致，可以用 binlog 同步去 pg 3. 网关对用户进行分流，新用户都在 B 服务，但是不太好回滚。 |
 |
4
shineshane 2023-01-29 15:33:37 +08:00
不停服我感觉没有什么完美的方案，低活跃时间段冷切换吧。
|
 |
5
wuxi889 OP @mercury233 停服是不可能停的
|
|
6
wuxi889 OP |
|
7
wuxi889 OP @picone 目前考虑的方案也是双写，但是还是有问题，A 服务的数据是异步写入的，切换过程后异步队列中可能还存在数据，这种常驻内存的代码还是执行原来写 A 服务的，所以这段代码就会丢失不会被双写入 B 服务
|
|
8
shineshane 2023-01-29 17:24:42 +08:00
@wuxi889 #6 没有低活跃时间段么？提前发个维护公告感觉也不是不行，夜间加班切换下。
|
|
9
picone 2023-01-29 17:24:57 +08:00
@wuxi889 #7 我没有理解，一条数据要不就是让 A 处理，要不就是让 B 处理，无论是哪个服务处理都得写两个数据库。
其实你把新服务当成是能灰度发布就行了，会存在中间态。 |
|
10
shineshane 2023-01-29 17:28:03 +08:00
@picone 我有个疑问，就是双写双读的时候要发布新版本才可以做到，那么如何保证热发布时两个数据库的状态一致呢？
|
 |
11
opengps 2023-01-29 17:29:43 +08:00
热更新难度很大，里面很多细节，平滑过渡需要存在同时写的一个阶段。
偷懒的做法，就是停机维护 |
|
12
perfectlife 2023-01-29 17:35:48 +08:00
@wuxi889 我其实还是想说没啥不能停的，停服比出事故再去急救简单多了，银行 /腾讯 /阿里 /字节 该停不还是停，停服嘛 不丢人
|
 |
13
kindjeff 2023-01-29 17:37:01 +08:00
停机
|
|
14
shineshane 2023-01-29 17:40:28 +08:00
我的想法就是，不停机就是在找不自在，所有的方案都不完美，都是在拆东补西，用不在意的东西换在意的东西。
|
|
15
picone 2023-01-29 18:26:27 +08:00
@shineshane #10 如果讲强一致的话，那问题就复杂了，回滚之类的。看业务场景，我们之前的场景只需要保证数据能写入就行，所以没所谓。
就像你所说的，所有方案都不完美哈哈。其实只要适合业务就行了，会有一定的容忍度。 |
 |
16
LifStge 2023-01-29 19:03:01 +08:00
热更也不是不行 但是很麻烦 要处理好所有差异的细节 很容易出问题
同时跑 然后热更一个中间层做兼容 能迁新就走新 然后等迁移完了 旧的没有使用的了 再热更 把兼容层下了 |
 |
18
killva4624 2023-01-30 10:37:36 +08:00
别的前面大佬们都说过了，做好要回切旧服务时候的预案。
|
Select Language