你简单说一下，你现在说的这个功能，是要实现用户上线后，对离线的拉取吗？

引用：完蛋 发表于 2020-11-10 16:59
是要将拉取消息的逻辑处理和服务端推送消息的逻辑处理变成一种，现在我们拉取消息的和推送消息的客户端处 ...

我不如这么问你，你现在的系统里：

• 1）具体有哪些消息是走的推？
• 2）具体有哪些消息是走的拉？
• 3）推和拉结合，是发生在什么具体的功能或业务下的？
  

你按我上面的问题回答，然后我看看你到底纠结的是什么，并给你合适的建议。

引用：完蛋 发表于 2020-11-11 08:25
1).我们在进入某个房间之后，所有该时间戳之后的消息使用推送逻辑
2).我们加载历史消息的时候，使用拉取 ...

看懂你的需求了，我的建议是，把所有的逻辑全用“拉取”实现，否则你们的弯路有的走。立贴为证！

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

是的，推送跟拉取逻辑混在一起，加重了你各种功能的复杂度，不信你们跳出推送这个思路，用拉去考虑，绝对没这么乱

引用：完蛋 发表于 2020-11-11 11:44
谢谢您的思路，我试试所有需求是否可以使用拉取去实现

嗯，一定要这么去想

引用：tingyanshen 发表于 2020-12-04 06:57
切换组了，就将pull_task全部关闭掉就可以了。这有什么好纠结的。

我对楼主的遭遇感同身受，他现在遇到的问题不只是技术上的，因为im涉及的技术栈要好几个端一起，随便改个逻辑都是一顿扯皮。。。

引用：完蛋 发表于 2020-12-04 17:49
今天对屎堆又有新需求了，发现可怕的事只是冰山一角，妈的业务端也是异步的，我们也是异步的，可操作redi ...

感觉你这工作干不长啊，年底了，看看工资涨不涨，年终奖发不发，年后该走人就走人了