[讨论] 关于IM消息增量拉取问题，比如seq序号导致的收发顺序问题

服务端没有采用离线消息全量推送的方案，只有一个数据库，即离线消息的获取是采用按需分页拉去的模式同时每个用户或者群聊的会话都会生成一个Seq序列号，每个序列号都是等差递增
客户端在用户收发消息的同时会判断序列号中是否存在断链，如果存在断链的情况会去服务器拉去历史消息，防止消息丢失的情况
那么这样子因为消息的时序问题导致用户A和用户B同时发送消息，可能用户A的消息先到达服务器先拿到seq，然而B的消息却先到达客户端，此时客户端会认为消息断链了，就会去服务器拉取历史消息，拉取完成后渲染到本地消息，此时用户A发送的消息返回发送成功Seq比客户端最新的Seq要更小且用户A发送的消息已经从拉取历史消息中拉去下来并渲染了。

同时，如果说在收到不正确的顺序的消息时，客户端会去拉取历史消息，如果这个时候历史消息的请求还没有返回，此时其他seq的消息已经到达客户端。也会存在客户端渲染的问题。

总之我感觉因为这个时序 和 断链 会导致很多问题。

像这种有其他好的解决方案吗

在线的情况下，实时接收和拉取两种逻辑同时存在，确实会存在你说的这种情况。
我的建议就是，离线拉取只在重新登陆或者掉线重连后拉取一次，一旦它上线了就只收实时消息。不在把逻辑搞复杂

站长说的好 ，在这个基础上我再补充下想法：
服务侧可能由于各种原因导致在线丢了少量消息；
客户端可以调整拉取时机：比如进入会话检查拉取一次； 定时兜底检查会话是否需要拉取（这里的延时肯定能覆盖你说的A，B同时或几乎同时发消息）

最靠谱的 seq 生成者，应该是客户端直接连接的接入层服务（暂且叫 gateway 服务），gateway 服务生成 seq 并严格递增，按照下行消息的推送顺序进行标记。客户端发现收到的消息 seq 断开的情况，直接在长连接通道向自己的接入层服务发送请求某个 seq 消息重新投递的消息体，接入层收到后重新投递指定 seq 的消息。这个方案优点是不会存在 seq 和实际投递顺序不一致的问题，但是缺点就是如果长连接断开重新连接，会连接到新的 gateway 重新计算 seq，不过断网重连的场景可以要求上游业务重新拉取消息。当然也可以让 gateway 写缓存来实现切换 gateway 时 seq 继续有效，不过这个看个人取舍，我是不喜欢让 gatewat 做任何数据 io 操作。

引用：researchboy 发表于 2023-08-22 22:43
最靠谱的 seq 生成者，应该是客户端直接连接的接入层服务（暂且叫 gateway 服务），gateway 服务生成 seq  ...

赞