求教，IM中计划采用读扩散的方式，但有些技术需要大家帮助

计划采用读扩散的方式，用户在收到新消息的时候，采取的是服务端推送《新消息通知》，然后客户端再去拉有哪些新消息的方式，现在有两个问题

1、服务端如何快速定位到用户是哪些会话有新消息？

2、服务端需要记录客户端拉取会话消息的最新位置（当然这个是每个会话都有一个），这个更新的时机是什么时候，是客户端拉取到消息之后再向服务端发一次请求吗（需要携带需要更新会话的最新消息id，这个最新id是每个会话的还是有一个更好的方式），比如定时去更新，或者两者都有？

引用：JackJiang 发表于 2021-01-03 19:39
im开发要做的事情和考虑的细节太多了，先大胆撸出来，小优化是不断进行的，不用急在一时，不然一开始考虑 ...

是啊，先动手开始做吧，现在主要是确定一个整体的基调，然后再针对细节进行设计和优化，太多了，技术和业务

引用：手写的从前 发表于 2021-01-03 13:14
主要是没做过哎，这的确是问题

im开发要做的事情和考虑的细节太多了，先大胆撸出来，小优化是不断进行的，不用急在一时，不然一开始考虑那么复杂，从零到一这个过程就很困难了。。。

引用：天黑请闭嘴 发表于 2021-01-03 11:45
感觉好多人都把这个推和拉的逻辑滥用了，前几天在群里也看到有类似的问题提出来......

主要是没做过哎，这的确是问题

引用：JackJiang 发表于 2021-01-03 11:44
完全可以。服务端的工作是：推送的消息宁多勿漏，客户端的工作是进行幂等去重。
千万别把服务端的逻辑搞 ...

好的哈，多谢了！

感觉好多人都把这个推和拉的逻辑滥用了，前几天在群里也看到有类似的问题提出来......

引用：手写的从前 发表于 2021-01-02 23:14
好的，大概了解了，多谢！
抛开新设备登陆不说，一个正常的设备在线状态时候，假如一个会话有新的消息， ...

完全可以。服务端的工作是：推送的消息宁多勿漏，客户端的工作是进行幂等去重。
千万别把服务端的逻辑搞复杂，im里服务端越往深水区走越多难点，服务端的逻辑保持越简单，以后的扩展就越好做

引用：JackJiang 发表于 2021-01-02 22:30
在线的情况下，长连接通道就是不了高效及时的进行消息的实时推送，只有在离线后再次上线时消息多的情况下考 ...

好的，大概了解了，多谢！
抛开新设备登陆不说，一个正常的设备在线状态时候，假如一个会话有新的消息，推送的我理解应该是这个设备上次读取的最新位置以后的消息。  举例来说 1 2 3 三条消息，1因为不可知的原因推送失败了，推送2的时候也会把1带上吗（服务端认为1没有成功）？然后靠客户端去重去保证消息一定可以到达

在线的情况下，长连接通道就是不了高效及时的进行消息的实时推送，只有在离线后再次上线时消息多的情况下考虑推拉相结合，你别理解错了。