IM的未读数各大IM厂商是怎么实现的？

IM的未读数看起来是一个很简单的功能，但是我感觉没那么简单啊？我的场景是同时在线用户量百万级，日消息量50亿量级，峰值QPS140w，不能丢消息的企业办公IM产品，支持多端同步，跟钉钉飞书一样的东西。

我们目前的方案是未读数客户端自己算，这有个前提是客户端上线后需要拿到全部离线消息才能开始统计，但是上线后拿到全部离线消息这个操作比较重，尤其是离线消息过多的时候耗时较长，另外离线消息因为服务端有时间和条数限制，如果超出限制后，逻辑开始变的复杂。

如果未读数在服务器计算，初步判断计算量就很大，如果一定要服务器算一定是异步去计算，因为计算延迟也会导致服务器计算的未读数并不实时。

特别想了解下各大IM云厂商的未读数是什么方？

引用：chenygs 发表于 2025-10-24 18:09
多设备可以这样做啊，本地存储每个会话的已读最大seq, 其读到哪里就同步到服务端已读到哪个seq,  另一个 ...

你大概是做过这个功能

引用：Frank 发表于 2025-03-07 14:26
要充分考虑加上多设备的情况

多设备可以这样做啊，本地存储每个会话的已读最大seq, 其读到哪里就同步到服务端已读到哪个seq,  另一个设备去拉取会话列表的时候，比较这个设备的这个会话的本地seq与返回的 服务端给的已读的seq比较，哪个大用哪个，然后在求这个会话最大seq与前面比较后的最大的seq的差值，就得到未读数啊啊

要充分考虑加上多设备的情况

引用：iamjason 发表于 2025-02-27 18:51
为什么要拉取离线消息，是因为是写模式吗？

每条消息都有seq, 每个会话有最大消息seq，每个会话存储你 ...

业务不复杂的时候这是一种方案；
但钉钉不是这种方案

引用：寒武三叶虫1 发表于 2025-02-10 11:10
客户端有本地缓存这个我知道，我的意思是客户端利用本地缓存计算未读数首先得本地缓存是最新的，
断线重 ...

为什么要拉取离线消息，是因为是写模式吗？

每条消息都有seq, 每个会话有最大消息seq，每个会话存储你读到哪个seq了， 用最大的seq减去你读到的seq就等于这个会话的未读数。所有会话的未读数加起来=总未读数

引用：JackJiang 发表于 2025-02-08 16:02
客户端都有本地缓存，加入未读数的基本只有两种情况：收到的新消息、拉取的离线消息。这都可以算入未读消 ...

客户端有本地缓存这个我知道，我的意思是客户端利用本地缓存计算未读数首先得本地缓存是最新的，
断线重连或者登录那一刻客户端就得把离线消息同步到本地，否则未读数计算的就不准了，
这里就涉及到离线消息同步的几个问题：
1. 离线消息可能很多同步时间很长，导致用户登录后页面卡顿。
2. 可能因为客户端长时间不在线，离线消息太多被服务端删除了部分，这种情况下的离线消息同步更麻烦了，因为企业内部的IM是不允许丢消息的，因此云厂商的IM离线超过7天的消息丢弃策略是不能接受的。

我了解到的钉钉的策略是在离线消息太多的时候会进行rebase操作，不知道他们的rebase是怎么做的。

引用：寒武三叶虫1 发表于 2025-02-08 15:04
文章里提到的，进入app后，主动在APP内用真实的未读数来设置一下，，，这里的真实的未读数从哪来的？从 ...

客户端都有本地缓存，加入未读数的基本只有两种情况：收到的新消息、拉取的离线消息。这都可以算入未读消息数

引用：JackJiang 发表于 2025-02-08 12:08
你读一读我在这个帖子里2楼的回复《求教IM的ios端未读消息数应该如何统计(比如APP角标上的未读数)》

文章里提到的，进入app后，主动在APP内用真实的未读数来设置一下，，，这里的真实的未读数从哪来的？从服务端获取的？还是客户端本地统计的？

你读一读我在这个帖子里2楼的回复《求教IM的ios端未读消息数应该如何统计(比如APP角标上的未读数)》