这是一个创建于 1207 天前的主题，其中的信息可能已经有所发展或是发生改变。
是这样的，最近有人告诉我说，为了避免消息丢失，状态不更新的问题，然后啥都搞个一直轮询的逻辑。比如 redis 的消息订阅，kafka 的消息等，大家都是这样设计的嘛？是不是太自愈。
 |
1
PerFectTime 2022-07-11 21:07:35 +08:00
还以为你说系统有 bug ，没人管他过一会自己就好了
|
 |
2
S2Line 2022-07-11 21:10:34 +08:00 via iPhone
redis 可以做降级和自愈，提高系统健壮性。
|
 |
3
bthulu 2022-07-12 08:40:42 +08:00
是的, 推送不靠谱, 必须有轮询来兜底
|
 |
4
Junzhou 2022-07-12 09:46:16 +08:00
跟一下 3 楼。是的，三方回调通知有可能会丢（比如网络链路拥塞等），必须有轮询来兜底
|
 |
5
julyclyde 2022-07-12 09:52:59 +08:00
如果遇到消息丢失，应该去修理消息丢失啊
1 为什么要用轮训去补 2 用了轮训是不是就打算无视消息丢失这个故障了？ |
 |
6
ql562482472 2022-07-12 10:40:12 +08:00
@julyclyde 消息丢失始终都会出现的，不可能完全解决，只能说尽可能降低概率，所以轮询是兜底和最可靠的解决方案
|
 |
7
nothingistrue 2022-07-12 11:04:12 +08:00
@julyclyde #5 消息丢失是订阅方的问题，不是发布方的问题。RabbitMq Exchange 就是个典型，消费方下线的时候，生产方发布的消息就奔向太空了。
说轮询弥补消息丢失其实不完全对，真正弥补消息丢失的，是发布方保存（暂存）消息+订阅方轮询。 |
Select Language