总阅读量:次

⭐⭐⭐ Spring Boot 项目实战 ⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》 《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》 《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》 《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》 《Java 面试题 + Java 学习指南》

摘要: 原创出处 www.toutiao.com/i6686735232772604429 「小猿学习笔记」欢迎转载，保留摘要，谢谢！

🙂🙂🙂关注**微信公众号：【芋道源码】**有福利：

  1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
  2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
  3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
  4. 新的源码解析文章实时收到通知。每周更新一篇左右。
  5. 认真的源码交流微信群。

一朋友和我讨论他前段时间面试某大公司的一题目 ：

企业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;
};

struct GroupMetaInfo 
{
 vector <UserInfo> members;
 string name;
 uint32_t maxid;
 // other info
};

这样群成员每加入一个群里，就有mapid<->usreid的双向映射了，假如群里有5个成员ABCDE, 那就对应mapid 1-5，messageid对应的消息详情存储就可以设计成

{ 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存储成本远超过最初的方案，可以用最初的方案来实现，客户端提前埋好兼容逻辑就可以了

文章目录