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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

嗯，一定要这么去想

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

引用：完蛋 发表于 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去过滤哪个，就看收取的顺序了。

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

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

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

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

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

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