• 头条面试官:如何设计群聊消息的已读未读功能?懵了。。


    来源:https://www.toutiao.com/i6686735232772604429

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

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

    这是个粗略的方案,里面还有一些细节值得思考:

    1. 退出的成员呢?比如C退出群,发消息时maxid还是5,已读+未读总人数应该是3(不包括发消息者本人),目前信息只有5个bit(0/1),识别不出来谁已经退出群聊了
    2. 退出群聊的成员如何处理?从GruopMetaInfo里面删除么?退出群聊成员重新加入又如何分配id呢?

    首先2这个点,退出群聊的成员只能标记删除,不能物理删除,不然客户端展示已读未读详情时,通过mapid找不到对应的userid,退出的成员又重新加入群聊这个就好办了,把标记删除改成非标记删除,还是用旧的mapid

    至于1呢? 我目前想到比较好的方式就是再加多一个bitmap,记录成员在消息发送时是否已经退出群聊了,退出群聊就置为1, 所以最终方案就是

    群信息增加userid,自增mapid双向映射,退出群聊成员标记删除,messageid 已读未读详情存储 {maxid, readbit[], quitbit[]}

    新的方案带来怎样的收益呢?

    1. 增加自增mapid字段,一个群聊维护一份,成本几乎可以忽略不计
    2. 每个成员已读未读由8B(64bit)优化成2bit,减少62/64, 200人已读未读旧的方案1600B, 现在只需要(200/8) * 2 + 4 = 54 , 每条消息节约95%+

    如果maxid如果到百万甚至千万级别,那岂不是灾难?一般实际场景,群聊是会限制人数的,就算不断踢人加新人,那maxid最多也只能到企业人数。 如果maxid达到一个特别大数字,已读未读对应的存储可以增加多一个flag,如果bitmap存储成本远超过最初的方案,可以用最初的方案来实现,客户端提前埋好兼容逻辑就可以了

    近期热文推荐:

    1.1,000+ 道 Java面试题及答案整理(2022最新版)

    2.劲爆!Java 协程要来了。。。

    3.Spring Boot 2.x 教程,太全了!

    4.Spring Boot 2.6 正式发布,一大波新特性。。

    5.《Java开发手册(嵩山版)》最新发布,速速下载!

    觉得不错,别忘了随手点赞+转发哦!

  • 相关阅读:
    通过百度地图API实现搜索地址--第三方开源--百度地图(三)
    对图片进行各种样式裁对图片进行各种样式裁剪:圆形、星形、心形、花瓣形等剪:圆形、星形、心形、花瓣形等--第三方开源--CustomShapeImageView
    仿UC天气下拉和微信下拉眼睛头部淡入淡出--第三方开源--PullLayout
    【英语】Bingo口语笔记(14)
    【前端】HTML入门笔记
    【英语】Bingo口语笔记(13)
    【英语】20141013 生词
    【英语】20141011 生词
    【Android】Android 学习记录贴
    【英语】Bingo口语笔记(12)
  • 原文地址:https://www.cnblogs.com/javastack/p/15824976.html
Copyright © 2020-2023  润新知