是这样的，最近有人告诉我说，为了避免消息丢失，状态不更新的问题，然后啥都搞个一直轮询的逻辑。比如 redis 的消息订阅，kafka 的消息等，大家都是这样设计的嘛？是不是太自愈。
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
This topic created in 1428 days ago, the information mentioned may be changed or developed.
 |
1
PerFectTime Jul 11, 2022
还以为你说系统有 bug ，没人管他过一会自己就好了
|
 |
2
S2Line Jul 11, 2022 via iPhone
redis 可以做降级和自愈，提高系统健壮性。
|
 |
3
bthulu Jul 12, 2022
是的, 推送不靠谱, 必须有轮询来兜底
|
 |
4
Junzhou Jul 12, 2022
跟一下 3 楼。是的，三方回调通知有可能会丢（比如网络链路拥塞等），必须有轮询来兜底
|
 |
5
julyclyde Jul 12, 2022
如果遇到消息丢失，应该去修理消息丢失啊
1 为什么要用轮训去补 2 用了轮训是不是就打算无视消息丢失这个故障了？ |
 |
6
ql562482472 Jul 12, 2022
@julyclyde 消息丢失始终都会出现的，不可能完全解决，只能说尽可能降低概率，所以轮询是兜底和最可靠的解决方案
|
 |
7
nothingistrue Jul 12, 2022
@julyclyde #5 消息丢失是订阅方的问题，不是发布方的问题。RabbitMq Exchange 就是个典型，消费方下线的时候，生产方发布的消息就奔向太空了。
说轮询弥补消息丢失其实不完全对，真正弥补消息丢失的，是发布方保存（暂存）消息+订阅方轮询。 |
Select Language