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
别的前面大佬们都说过了,做好要回切旧服务时候的预案。
|