群聊消息“已读”/“未读” 功能解决方案!
一朋友和我讨论他前段时间面试某大公司的一题目:
企业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存储成本远超过最初的方案,可以用最初的方案来实现,客户端提前埋好兼容逻辑就可以了。
作者:小袁学习笔记
来源:www.toutiao.com/i6686735232772604429/
群聊消息“已读”/“未读” 功能解决方案!相关推荐
- IM群聊消息的已读未读功能在存储空间方面的实现思路探讨
1.引言 IM系统中,特别是在企业应用场景下,消息的已读未读状态是一个强需求. 以阿里的钉钉为例,钉钉的产品定位是用于商务交流,其"强制已读回执"功能,让职场人无法再"假 ...
- 面试官:群聊消息的已读未读功能,你来设计一个?
欢迎关注方志朋的博客,回复"666"获面试宝典 一朋友和我讨论他前段时间面试某大公司的一题目 : 企业IM比如企业微信.钉钉里面的群消息的有个已读未读的功能,发送者刚发出消息时,当 ...
- 大公司面试考细节,设计群聊消息的已读未读功能你说说怎么做?
一朋友和我讨论他前段时间面试某大公司的一题目 : 企业IM比如企业微信.钉钉里面的群消息的有个已读未读的功能,发送者刚发出消息时,当前群里其他群成员都是未读状态,陆陆续续有人看了这个消息,这时候消息的 ...
- 面试题:群聊消息的已读未读设计
点击上方"Java之间",选择"置顶或者星标" 你关注的就是我关心的! 作者:小猿学习笔记 一朋友和我讨论他前段时间面试某大公司的一题目 : 企业IM比如企业微 ...
- IM消息重试机制Java实现_IM群聊消息的已读回执功能该怎么实现?
本文引用了架构师之路公众号作者沈剑的文章,内容有改动,感谢原作者. 1.前言我们平时在使用即时通讯应用时候,每当发出一条聊天消息,都希望对方尽快看到,并尽快回复,但对方到底有没有真的看到?我却并不知道 ...
- Android已读未读功能,android – 将SMS消息标记为已读/未读或删除在KitKat中不起作用的消息...
我一直在研究短信应用程序.直到昨天,当我将Nexus 4更新为 Android 4.4,KitKat时,一切顺利.诸如将SMS标记为已读/未读以及删除线程中的所有消息等功能已停止工作.为什么会这样?它 ...
- vue+websocket+nodejs实现聊天室 - 消息已读未读
前言 上一篇讲了聊天室增加一对一单聊,这次讲如何新增已读未读状态. 大概思路: 服务器返回消息列表,增加参数status为1,单聊和群聊通过过滤状态区分对应未读数量,当前聊天,直接在currentMe ...
- Redis实现排行榜、延迟队列、LRU、消息已读未读(Redisson客户端实现)
目录 序言 Redis客户端选型 Redis配置 Redis实现排行榜 Redis实现延迟队列 Redis LRU(Least Recently Used)使用 Redis实现消息已读未读 总结 序言 ...
- Web聊天室消息[已读未读]的实现
聊天室快速访问 继上次完成聊天室的历史记录功能后,我又想着实现聊天记录的已读未读功能.(轻喷..) 开始之前 首先我看了抖音和钉钉这两款应用的消息已读未读功能的呈现效果.首先是抖音,在聊天界面,给好友 ...
最新文章
- 通用权限管理系统组件 中集成多个子系统的单点登录(网站入口方式)附源码
- 【Flutter】Dart 数据类型 Map 类型 ( 创建 Map 集合 | 初始化 Map 集合 | 遍历 Map 集合 )
- python识别简单训练模型_Python3+OpenCV实现简单交通标志识别
- r语言remarkdown展示图_R语言—自动报告Markdown笔记
- Kubernetes PV/PVC/StroageClass 持久化存储简介
- 小程序使用腾讯API定位的全过程(详细)
- 三菱伺服自动调谐_三菱伺服mr-j3与mr-j4参数有什么差别
- 税务会计实务【15】
- html计时加速,HTML-加速、再加速(下)_html
- 轻型异常在线检测器LODA:Lightweight on-line detector of anomalies
- mmorpg无缝地图
- 教育直播APP开发发展前景浅析!
- 案例2:随机森林来填补缺失值
- S5PV210 GPIO驱动及其在android2.3.1下jni调用
- 拉卡拉的十四年和第三次成人礼
- 简体字---繁体字---网页简体字转繁体字--包教包会
- ORB_SLAM3的安装与测试
- 一、SpringMVC基础入门,创建一个HelloWorld程序
- 书上得来终觉浅,绝知此事要躬行-以太坊平台实战篇
- C/C++面试:尽量以const、enum、inline替换#define