求助关于IM消息推送和拉取如何共存?

        因为leader要求群聊的客户端推送和拉取的代码解耦，但在分析中发现推送代码和拉取代码重叠了。主要是服务器异步处理的时候打乱了消息的序列号顺序，导致可能序列号不连续，然后为了可靠性，客户端读到未连续的消息会再次拉取消息，所以推送过来的处理代码和拉取代码耦合了，然后逻辑混乱了。现在想的策略只有我们拉取的代码不是等待拉取结果而是等待推送结果，服务器只推送不回应拉取，但因为服务器这边是在拉取之后再推送所以很难处理。现在就卡住了。leader认为这个方案不怎么好？请问还有方案可以试试吗？

引用：JackJiang 发表于 2020-11-10 15:37
你简单说一下，你现在说的这个功能，是要实现用户上线后，对离线的拉取吗？

是要将拉取消息的逻辑处理和服务端推送消息的逻辑处理变成一种，现在我们拉取消息的和推送消息的客户端处理逻辑不一样，所以但这两个逻辑又因为弱网或者换组之类的操作推送消息的逻辑处理又调用了拉取消息的逻辑。所以我要么全变成一种逻辑，要么将其共用的函数抽离出来。当然最好是改为一种处理逻辑，不过因为有业务需求（业务里如果只有推送的话，因为推送的时候要看服务器会不会改组，所以推送过来的消息要判断是否要拉取消息）。总之两种方法我都和leader讨论了，结果我现在因为业务的需求两边都优化不了。只是抽离了代码，没有减少逻辑判断和代码量。

引用：JackJiang 发表于 2020-11-10 19:33
我不如这么问你，你现在的系统里：

1).我们在进入某个房间之后，所有该时间戳之后的消息使用推送逻辑
2).我们加载历史消息的时候，使用拉取消息逻辑
3).我们处理由于网络产生的推送序列号不连续问题使用拉取消息逻辑，处理由于推送时自动换组业务也会使用拉取消息逻辑(leader告诉我是为了保障不会有消息缺失).
4).最后推送和拉取这里处理存储的逻辑是一样的底层逻辑。

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

还有我们因为要处理撤回消息，所以保存了所有的组内消息索引快照，搞得因为这个业务撤回消息的逻辑非常复杂。因为撤回消息也是一条消息，我们服务端扩散推送的时候是并发的，所以不能保证撤回消息与真正消息的顺序。请问一般处理群聊撤回消息的解决方案是什么？

引用：JackJiang 发表于 2020-11-11 11:07
是的，推送跟拉取逻辑混在一起，加重了你各种功能的复杂度，不信你们跳出推送这个思路，用拉去考虑，绝对 ...

谢谢您的思路，我试试所有需求是否可以使用拉取去实现

刚想解决的时候又和leader讨论了解决中的问题，结果leader告诉我由于业务需求，我们记录消息拉取的时间戳可能出现的bug。当用户在群聊1组时，有4条消息红点，结果进去的时候可能改组了（我们服务器会自动改组）,然后同时拉来了一条消息(每次进去都会拉取这个组离线消息)，mygod,服务器换的组，用户自己换回去也不能收到那四条消息了，因为用户只能接收同一时间段一个组的消息，用户拉了2组的消息就不能拉1组的，就算是我们帮用户拉的也不行。

引用：JackJiang 发表于 2020-12-04 12:14
我对楼主的遭遇感同身受，他现在遇到的问题不只是技术上的，因为im涉及的技术栈要好几个端一起，随便改个 ...

今天对屎堆又有新需求了，发现可怕的事只是冰山一角，妈的业务端也是异步的，我们也是异步的，可操作redis都是一样的，只是我们是websocket他们是http,然后我们的操作会被他们影响，太多代码是因为他们的操作我们擦屁股。淦