1
wysnylc 2020-10-26 12:26:29 +08:00
增加幂等机制防止服务中心重启后重复提交
|
2
sadfQED2 2020-10-26 12:32:06 +08:00 via Android
注册中心都宕机了,那和机房停电断网差不多了吧
|
3
Cbdy 2020-10-26 12:57:46 +08:00
拉取注册信息的时候异步缓存一份,注册中心挂了发告警走缓存,在缓存的内容都失效了之前赶紧故障恢复
|
4
zhgg0 2020-10-26 13:04:34 +08:00 2
客户端一般会缓存服务端的列表,只是服务提供方列表变动没法通知到客户端了,rpc 调用没啥影响,新服务提供方上线没法使用,下线依赖客户端自己调用失败后才能发现。
|
5
bleepbloop 2020-10-26 13:17:11 +08:00
通知 oncall 的人处理一下
|
6
DebugTy 2020-10-26 13:41:40 +08:00
如果是 dubbo, 确实客户端会有缓存服务端接口信息,其实影响不大的,加上完善的报警机制及时处理很快注册中心就恢复正常了
|
7
lau52y 2020-10-26 14:20:57 +08:00 via iPhone
😄这问题,跟一万个为什么一样
|
8
yinft 2020-10-26 15:32:33 +08:00
@bleepbloop 太真实了
|
9
nnnToTnnn 2020-10-26 16:02:18 +08:00
在不考虑机房的情况下下。
1. 通过虚拟 IP 进行访问,如果一台注册中心宕机了,那么应该里面由其他 IP 来进行执行对应的人。 2. 如果虚拟 IP 出现问题,应该紧急通过域名转发切换到其他的 IP 地址。 这种灾备的方案一大堆,只要数据库数据不乱,应用层基本上可以随便玩。当然补偿要做好 |
10
bleepbloop 2020-10-26 17:23:21 +08:00
@yinft 都已经宕机了,还能怎么办?难不成要事后诸葛亮一下么,哈哈哈哈哈哈哈
|
11
xiudongxu 2020-10-26 17:31:36 +08:00
情况 1:已经服务已经在运行中,并且没有新服务要发布的话,那完全 ojbk,不影响使用。
情况 2:如果需要发布服务的话,那直接 GG,服务就起不来了。 找负责的同学来恢复吧,稍等一会发布,问题不大。 |
12
beidounanxizi 2020-10-26 17:50:46 +08:00
宕机 也可以自动故障转移啊 我猜 不是走的共识算法么?为什么还需要考虑其他呢?好奇
|
13
yc8332 2020-10-26 18:02:57 +08:00
这个正常都有缓存吧。只是相当于写死了一样。。所以当然是靠人工去处理了。
|
14
daimazha 2020-10-27 15:45:47 +08:00
@bleepbloop #5 这很字节
|
15
bleepbloop 2020-10-27 18:15:53 +08:00
@daimazha 顶多加上一句:修好了以后要做个 postmortem 吧(狗头)
|
16
YouLMAO 2021-01-18 00:21:57 +08:00 via Android
不能 down,f 家广告一个请求需要经过 350 个左右的服务,down 了就没收入了
|