一朋友和我讨论他前段时间面试某大公司的一题目 :
企业IM比如企业微信、钉钉里面的群消息的有个已读未读的功能,发送者刚发出消息时,当前群里其他群成员都是未读状态,陆陆续续有人看了这个消息,这时候消息的详情变成x人已读,y人未读,如下图所示,有具体的已读未读列表(万恶的功能,看到同事or老板的消息不能假装没看到了),每条消息对应一个唯一的messageid(uint64_t),每个用户对应一个唯一的userid(uint64_t),应该如何保存这个消息对应的已读未读详情呢?

图片
我第一时间给出一个很简单粗暴的方案:
对于每一个messageid,存当前readids + unreadids,当群成员A已读某一条消息时,把A userid从unreadids移除写到readids上就好了,客户端更新到messageid对应的详情列表,就可以展示m人已读,n人未读
显然这么简单粗暴的方案面试官是不会满意的,追问有没有更好的方案呢?
仔细分析,按照目前的设计,每一条消息,已读未读详情就要占用8B * 群成员数的内存,如果一个活跃的200人大群,每发一条消息,已读未读就要1600B,如果平均每天消息量是1k,那每个这样的群,每天就要1.6MB磁盘空间,对于客户端来说,特别是手机端,占用磁盘空间是用户不能接受的,又不能把工作消息删了,对于服务器端来说,用户群体如果特别大,那数据库存储这个成本也不小
其实未读已读就是一个0/1的标记而已,可以维护一个bitmap来实现呢?具体应该怎么做呢?
群元信息保存userid到自增mapid的映射
struct UserInfo { uint64_t userid; uint32_t mapid;

本文探讨了如何设计企业IM群聊的已读未读功能,以降低存储成本和提高效率。提出使用bitmap来存储已读未读状态,通过自增mapid映射用户ID,同时处理成员退出和重新加入的情况。优化后的方案能显著减少存储空间,且具备扩展性和兼容性。
最低0.47元/天 解锁文章
386

被折叠的 条评论
为什么被折叠?



