引用：完蛋 发表于 2020-11-11 09:11
还有我们因为要处理撤回消息，所以保存了所有的组内消息索引快照，搞得因为这个业务撤回消息的逻辑非常复 ...

你撤回不等待该消息发送的结果吗？ 就是本地UI直接撤回，后台撤回的消息挂到待撤回消息的ack回调去。这样就确保了消息先发送到了服务端落地了，撤回消息才会发出去。 虽然服务端处理消息是分布式的，但是这样就保证消息和撤回消息处理有了顺序保证。 反向投递对于每一个用户来说，只要链路没问题，消息都会按照顺序发送。 除非失败重传。但是依然不能保证客户端会出现撤回消息先于消息到达的情况。所以服务端完全可以不考虑，直接客户端过滤。 若是客户端先收到撤回消息，就将接下来收到的消息和撤回消息匹配，匹配到了就移除掉。后续就不需要匹配了 (filter_queue.size = 0). 其实反过来，先收到消息，后收到撤回消息，也同样可以使用这种过滤的方式。只不过两者执行的逻辑有点不一样。

引用：完蛋 发表于 2020-11-11 13:48
刚想解决的时候又和leader讨论了解决中的问题，结果leader告诉我由于业务需求，我们记录消息拉取的时间戳可 ...

切换组了，就将pull_task全部关闭掉就可以了。这有什么好纠结的。

引用：完蛋 发表于 2020-11-11 09:11
还有我们因为要处理撤回消息，所以保存了所有的组内消息索引快照，搞得因为这个业务撤回消息的逻辑非常复 ...

这个服务端也无法避免。无论如何保证，最终在网关推送可能会因为网络的原因导致撤回消息先到，但是待撤回的消息却没到。 且不论两者在客户端的收取顺序到底是谁先谁后。其实都可以通过filter_queue的方式去处理，存放的都是message_id. 至于用这个message_id去过滤哪个，就看收取的顺序了。