虽然一开始就想到了最后的步骤，不过一步一步跟着思路走还是能弥补自己的思维局限

请问怎么计算未读数呢？

引用：某非著名程序 发表于 2021-03-14 19:10
看了好几遍，我是客户端开发者。有一个疑问
群消息存储一个列表，那个客户端拉取到了那条消息，客户端本身 ...

服务端存的话，要是你客户端卸载过，再次安装时就能精确加载增量的离线消息，否则就麻烦了

看了好几遍，我是客户端开发者。有一个疑问
群消息存储一个列表，那个客户端拉取到了那条消息，客户端本身是知道的。服务端是不是就不需要存储time（或者msg_id）?

群聊缓存消息，怎么触发去删除呢？

引用：JackJiang 发表于 2019-09-23 20:19
对于服务端来说，这种异常的ACK，应该有个容错的逻辑

@JackJiang    容错的逻辑能给个具体的思路吗? 另外,这个容错的机制是不是放在客户端判断比较好?

引用：eng 发表于 2019-09-23 16:52
@JackJiang   不是,我不担心4和6拉取重复; 我担心按msg_id > 5 拉取群离线消息,没有拉取到msg_id=4的这条 ...

对于服务端来说，这种异常的ACK，应该有个容错的逻辑

引用：JackJiang 发表于 2019-09-23 14:51
你是在担心：实际上4、6已被收到的情况下，如果服务端再存4、6离线的话，下次拉取就会存在4、6在接收者那 ...

@JackJiang   不是,我不担心4和6拉取重复; 我担心按msg_id > 5 拉取群离线消息,没有拉取到msg_id=4的这条消息

引用：eng 发表于 2019-09-23 13:33
@JackJiang

接收者在线收到了msg_id=4,5,6的这三条,  但msg_id=4和msg_id=6的ACK没有成功, 那msg_id= ...

你是在担心：实际上4、6已被收到的情况下，如果服务端再存4、6离线的话，下次拉取就会存在4、6在接收者那边重复的情况吗？

引用：JackJiang 发表于 2019-09-23 13:08
你这说的好乱，你直接说，接收者已经在线收到了哪几条，离线了哪几条

@JackJiang

接收者在线收到了msg_id=4,5,6的这三条,  但msg_id=4和msg_id=6的ACK没有成功, 那msg_id=4的这条怎么离线拉取出来?

引用：eng 发表于 2019-09-23 12:53
@JackJiang
如果按msg_id或者时间戳拉取群聊离线消息,遇到以下这种情况怎么处理,求指导.
客户端在线分 ...

你这说的好乱，你直接说，接收者已经在线收到了哪几条，离线了哪几条

引用：JackJiang 发表于 2019-04-19 21:36

@JackJiang
如果按msg_id或者时间戳拉取群聊离线消息,遇到以下这种情况怎么处理,求指导.
客户端在线分别收到msg_id为4,5,6的三条在线推送消息,客户端ACK时,msg_id为4和6的消息,ACK未被服务端收到;
客户端再次登录后,按msg_id拉取离线消息,只能拉取5和6,4必然丢失; 按时间戳也存在类似的问题,怎么办呢?

引用：jituijiaqiezi 发表于 2019-06-18 16:02
如果只有last_ack_msg_id,如果用户登录了去拉取数据，客户端还没返回拉取的ack，聊天通道就新发送了消息， ...

qq的设计原则是万有一失，方案没有完美的，能把异常控制在可接受范围内，也算是一种折中啦

如果只有last_ack_msg_id,如果用户登录了去拉取数据，客户端还没返回拉取的ack，聊天通道就新发送了消息，服务端收到在线的ack,那么这时候如果更新last_ack_msg_id，就可能出错了，这个问题怎么解决呢

引用：郑柳青 发表于 2019-04-19 12:15
其实不太想写评论，因为还没消化后提出好问题或者更好的解决方案。想把好位置给有价值的信息。 不过想想积 ...

其实不太想写评论，因为还没消化后提出好问题或者更好的解决方案。想把好位置给有价值的信息。 不过想想积极的评论也是对作者和传播者更大的鼓励。 喜欢阅读这种渐进式文章。 一步一步优化推进，已不是个人纪要，完全是教科书。赞👍

学习了，正在做相关工作。

引用：JackJiang 发表于 2019-01-02 18:23
文章里的方法，其实是目前主流移动端IM的做法，有一个好处就是：当用户的手机真正离线（也就是网络不可用 ...

是的，说的有道理，在离线情况下我这种体验确实不太好，可能用户点进去聊天界面后都是一片空白。
在网络时断时续的情况下，我倒觉得没有太大问题，因为这时就算是在线消息，也可能出现频繁发送、接收不到的坏体验，更何况离线消息了。

引用：weixiaoyao 发表于 2019-01-02 18:07
我们目前的离线思路是另一种，从业务层面弱化离线和在线的区别，群消息表内只存1条消息，send_id, group_id ...

文章里的方法，其实是目前主流移动端IM的做法，有一个好处就是：当用户的手机真正离线（也就是网络不可用的情况下——这可能是用户为了省流量或电量主动关闭的、也有可能是信号不好等等情况下）的时候，是可以完全脱机查看这些消息的。

而你的方案，在手机脱机这种场景下，其实是体验不好的，因为用户不可能及时地把所有未读消息界面都点过，或者说恰好点到这个界面的时候网络信息号好，那么此时好友或群有消息拉取体验就下降很多，而且你的方案会把这种不佳体验风险放大（在极端情况下，由于移动网络都懂或跳变的可能性很大，导致用户可能会频繁碰到这种体验问题）。

不过，没有绝对最优的方案，适合的就是最好的。