search

AlexStocks / alexstocks.github.io

AlexStocks's blog
Other
14 stars 7 forks source link

pubsub #4

Open AlexStocks opened 6 years ago

AlexStocks commented 6 years ago

https://alexstocks.github.io/html/pubsub.html

xrayw commented 4 years ago

作者您好, 关于您im中提到的超时重试的方案.

我发现开源im中采用的都是长连接和消息存储逻辑都在相同模块的处理方式, 这样超时重试只需要在长连接对应的这台实例针对这个长连接下发的用户消息添加程序内的定时任务就可以做到超时重试, 这样长连接关闭的时候可以简单的停止掉对应长连接的超时重发任务. (比如开源的mqtt, cim等)

但如果采用长连接只负责长连接, 和消息存储层的交互通过MQ来进行的话, 这样就不能只在一台实例上开启超时重试的任务, 而用redis的zset或者支持延迟消息的消息队列, 或多或少又会遇到像redis做任务不是非常可靠, mq延迟消息不支持取消这些问题.

请问您系统里这块是怎样处理的呢, 目前我是采用redis做定时任务的方案来实现的, 但这种方案在很多情况下还是会出问题. 还请您指教, 感谢👍🏻

AlexStocks commented 2 years ago

@UzimakiNaruto 作者您好, 关于您im中提到的超时重试的方案.

我发现开源im中采用的都是长连接和消息存储逻辑都在相同模块的处理方式, 这样超时重试只需要在长连接对应的这台实例针对这个长连接下发的用户消息添加程序内的定时任务就可以做到超时重试, 这样长连接关闭的时候可以简单的停止掉对应长连接的超时重发任务. (比如开源的mqtt, cim等)

但如果采用长连接只负责长连接, 和消息存储层的交互通过MQ来进行的话, 这样就不能只在一台实例上开启超时重试的任务, 而用redis的zset或者支持延迟消息的消息队列, 或多或少又会遇到像redis做任务不是非常可靠, mq延迟消息不支持取消这些问题.

请问您系统里这块是怎样处理的呢, 目前我是采用redis做定时任务的方案来实现的, 但这种方案在很多情况下还是会出问题. 还请您指教, 感谢👍🏻

你这引用的消息内容从哪里 copy 来的？我文中没有这段话啊