引用：JackJiang 发表于 2019-02-27 21:36
哪些群有新消息，服务端肯定是确切知道的，不需要客户端来按照这么多群一个个遍历拉取

服务端肯定是可以计算出，但问题的关键是效率。一个人的会话数很多的时候（无限建群模式），如何快速找到存在未读消息的会话列表才是问题的核心。

引用：一夕 发表于 2019-02-27 20:53
我个人觉得解决方案是建立在实际用户场景里的，对于im而言主要纠结在实时推送【多端问题、及时性、数据不 ...

看的出来是有经验的人，你可以整理整理你的一些经验，分享出来。这方面的资料还是很稀缺的

感觉last_ack_msgid都可以不维护，有客户端自己维护，能想到的就是有可能群组黑名单用户亦可拉取理应被屏蔽的消息，消息拉取行为完全有客户端自行决定

终极方案里，假设id递增的msg1，msg2，msg3；msg3应答了，msg2没有应答；这时last_ack_msgid该怎么处理呢

群玩家加入，退出的通知消息怎么办呢？1.为了保证这些消息每个玩家都能看到，这些通知需要写到消息里
2.但是又不能算做一条未读消息
导致我计算未读消息数的时候异常

我有个需求无法实现，群成员退出，加入消息，由于需要通知全员又不能丢失，只能作为消息发送到群里，这导致我的未读消息数处理异常，因为未读消息数是通过ID相减得出的

引用：一夕 发表于 2019-02-27 20:53
我个人觉得解决方案是建立在实际用户场景里的，对于im而言主要纠结在实时推送【多端问题、及时性、数据不 ...

我有个需求无法实现，群成员退出，加入消息，由于需要通知全员又不能丢失，只能作为消息发送到群里，这导致我的未读消息数处理异常，因为未读消息数是通过ID相减得出的

引用：dayuan555 发表于 2019-07-18 14:25
我有个需求无法实现，群成员退出，加入消息，由于需要通知全员又不能丢失，只能作为消息发送到群里，这导 ...

这个通知，也可以算进未读啊，没什么不合理

引用：JackJiang 发表于 2019-07-18 15:09
这个通知，也可以算进未读啊，没什么不合理

微信里，这些通知都没算，我们策划也要求不算

引用：dayuan555 发表于 2019-07-18 16:13
微信里，这些通知都没算，我们策划也要求不算

如果这样，那你就用指令类型区别，当收到是通知的话，就不加未读数

如果群聊中有删除功能，群成员可以把部分消息删除，A群成员删除了消息，不影响B群成员看到的消息。那么群消息只存一份是不是还不够？是不是需要额外的数据库表记录群成员删除了哪些消息

引用：gpshang 发表于 2019-08-13 18:18
如果群聊中有删除功能，群成员可以把部分消息删除，A群成员删除了消息，不影响B群成员看到的消息。那么群消 ...

消息本身虽然只有一份，但群成员各自已的消息id情况肯定是有个单独的表啦

引用：tsfeng 发表于 2019-04-19 12:01
终极方案里，假设id递增的msg1，msg2，msg3；msg3应答了，msg2没有应答；这时last_ack_msgid该怎么处理呢

我也同样存在这个疑问

引用：1mok 发表于 2019-03-06 18:06
服务端肯定是可以计算出，但问题的关键是效率。一个人的会话数很多的时候（无限建群模式），如何快速找到 ...

我和你有同样的疑问, 读扩散模式下如何快速找到有新消息的会话..
目前思路是不写db, 但要记在缓存里. 把有新消息的会话id记录下来.

学习了

引用：Sudo 发表于 2020-04-19 23:50
我和你有同样的疑问, 读扩散模式下如何快速找到有新消息的会话..
目前思路是不写db, 但要记在缓存里. 把 ...

性能上，放到缓存肯定是最优项。

客户端拉取携带服务端返回给他最新的last_ack_msgid，服务端只返回比last_ack_msgid大的消息列表给客户端？避免重复拉取。

引用：GarageBand 发表于 2020-09-04 20:11
客户端拉取携带服务端返回给他最新的last_ack_msgid，服务端只返回比last_ack_msgid大的消息列表给客户端？ ...

是的

微信生成消息ID 里提到按用户生成msgid，那群消息只存一份，群中各个用户的msgid和群消息是如何关联的？

引用：张小驰_q6jys 发表于 2020-10-29 15:35
微信生成消息ID 里提到按用户生成msgid，那群消息只存一份，群中各个用户的msgid和群消息是如何关联的？

群消息是一个表，每个群还有个群成员表，在群成员表上针对各人做文章