2022年5月17日 下午4:16 • 面试题 • 阅读 39   围观：  推荐一位大神朋友 一朋友和我讨论他前段时间面试某大公司的一题目 ： 企业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的映射 { uint32_t maxid, uint8_t readbit[]} 如上面的案例就是{5, readbit[0] =bin(0000 0000)}; 就占用了5B(4+1),A发消息，D已读消息时，就更新成{5,readbit[0]= bin(0000 1000)},其余4人都已读消息时 更新为{5, readbit[0]=bin(0001 1110)} 这是个粗略的方案，里面还有一些细节值得思考： 退出的成员呢？比如C退出群，发消息时maxid还是5，已读+未读总人数应该是3(不包括发消息者本人)，目前信息只有5个bit（0/1），识别不出来谁已经退出群聊了 退出群聊的成员如何处理？从GruopMetaInfo里面删除么？退出群聊成员重新加入又如何分配id呢？ 首先2这个点，退出群聊的成员只能标记删除，不能物理删除，不然客户端展示已读未读详情时，通过mapid找不到对应的userid，退出的成员又重新加入群聊这个就好办了，把标记删除改成非标记删除，还是用旧的mapid 至于1呢？我目前想到比较好的方式就是再加多一个bitmap，记录成员在消息发送时是否已经退出群聊了，退出群聊就置为1, 所以最终方案就是 群信息增加userid，自增mapid双向映射，退出群聊成员标记删除，messageid 已读未读详情存储 {maxid, readbit[], quitbit[]} 新的方案带来怎样的收益呢？ 增加自增mapid字段，一个群聊维护一份，成本几乎可以忽略不计 每个成员已读未读由8B（64bit）优化成2bit，减少62/64, 200人已读未读旧的方案1600B, 现在只需要(200/8) * 2 + 4 = 54 ， 每条消息节约95%+ 如果maxid如果到百万甚至千万级别，那岂不是灾难？一般实际场景，群聊是会限制人数的，就算不断踢人加新人，那maxid最多也只能到企业人数。 如果maxid达到一个特别大数字，已读未读对应的存储可以增加多一个flag，如果bitmap存储成本远超过最初的方案，可以用最初的方案来实现，客户端提前埋好兼容逻辑就可以了 感谢阅读，希望对你有所帮助 :)  来源：www.sxzhongrui.com/i6686735232772604429 主流java进阶技术（学习资料分享） 与其在网上拼命找题？ 不如马上关注我们~ PS：因为公众号平台更改了推送规则，如果不想错过内容，记得读完点一下“在看”，加个“星标”，这样每次新文章推送才会第一时间出现在你的订阅列表里。点“在看”支持我们吧！ 版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。 文章由半码博客整理，本文链接：https://www.sxzhongrui.com/index.php/post/8669.html