面试官：群聊消息的已读未读功能，你来设计一个？

最新推荐文章于 2025-10-07 08:00:00 发布
最新推荐文章于 2025-10-07 08:00:00 发布
阅读量386 收藏
点赞数
CC 4.0 BY-SA版权
分类专栏： 九阳神功 文章标签： java
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/qq_43409811/article/details/121332008
本文讨论了如何设计企业IM群聊中的已读未读功能，从最初的简单方案（存储readids和unreadids）到使用bitmap优化，通过分析内存和磁盘空间占用，提出了在成员退出和重新加入时的处理策略，并介绍了如何在MySQL和Redis中实现这一方案，以降低存储成本并提高效率。

企业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磁盘空间，对于客户端来说，特别是手机端，占用磁盘空间是用户不能接受的，又不能把工作消息删了，对于服务器端来说，用户群体如果特别大，那数据库存

了解本专栏 订阅专栏 解锁全文 超级会员免费看
知识付费：程序员的社群运营思维
AI天才研究院
10-29 1285
《知识付费：程序员的社群运营思维》 关键词： 知识付费、程序员、社群运营、用户需求、互动交流、数据分析 摘要： 本文旨在探讨知识付费背景下，程序员如何通过社群运营提升自
消息推送中的已读消息和未读消息设计难题
qq_63431773的博客
11-16 2347
站内信”有两个基本功能：用户给用户发送站内信，管理员给用户发送站内信。管理员给用户（指定满足某一条件的用户群）群发消息这两个功能实现起来也很简单｛如图｝。只需要设计一个消息内容表和一个用户通知表，当创建一条系统通知后，数据插入到消息内容表。消息内容包含了发送渠道，根据发送渠道决定后续动作。如果是站内渠道，在插入消息内容后异步的插入记录到用户通知表。这个方案看起来没什么问题，但实际上，我们把所有用户通知的消息全部放在一个表里面，如果有 10W 个用户，那么同样的消息需要存储 10W 条。
面试官：群聊消息的已读未读功能，你来设计一个?
superjava_的博客
12-30 413
一朋友和我讨论他前段时间面试某大公司的一题目 ： 企业IM比如企业微信、钉钉里面的群消息的有个已读未读的功能，发送者刚发出消息时，当前群里其他群成员都是未读状态，陆陆续续有人看了这个消息，这时候消息的详情变成x人已读，y人未读，如下图所示，有具体的已读未读列表（万恶的功能，看到同事or老板的消息不能假装没看到了），每条消息对应一个唯一的messageid（uint64_t），每个用户对应一个唯一的userid（uint64_t）,应该如何保存这个消息对应的已读未读详情呢？ 图片 我第一时间给出
数据结构面试--如何设计群聊消息的已读未读功能
dazhong2012的专栏
04-29 1879
在企业即时通讯(IM)软件中，如企业微信、钉钉等，群聊消息的已读未读功能是一个重要的特性。它不仅帮助用户了解哪些消息已经被阅读，还能促进信息的及时反馈和处理。在设计这一功能时，我们需要考虑存储效率、系统性能以及用户体验等多个方面。本文将探讨如何设计一个高效且实用的群聊消息已读未读系统。
app里未读消息已读、未读是怎么设计的？
关注我！带你一路 "狂飙" 到底！
03-03 4760
一款app，消息页面有：钱包通知、最近访客等各种通知类别，每个类别可能有新的通知消息，实现已读、未读功能，包括多少个未读，这个是怎么实现的呢？比如用户A访问了用户B的主页，难道用rabitmq给B发通知消息吗？量大了成本受得了吗？有没有成本低的方案呢
头条面试官：如何设计群聊消息的已读未读功能
hello world！
10-27 666
点击上方蓝色“java大数据修炼之道”,选择“设为星标” 每晚九点: 技术干货 ???? 必定奉上来源：toutiao.com/i6686735232772604429一朋友和我讨论他前段时间...
这样设计群聊消息的已读未读功能，领导给我发了奖金
程序员小乐
03-02 511
????推荐大家关注一个公众号????点击上方 "编程技术圈"关注,星标或置顶一起成长后台回复“大礼包”有惊喜礼包！每日英文Some troubles are made up by ourselve...
第124期:适合你实践的 10 个 LLM 与 RAG 项目
最新发布
全网120W+关注AI拉呱，专注人工智能以及科技前沿！
10-07 3157
以下是文章摘要（150字以内）： AI赋能创新：10个RAG技术应用项目盘点 本文介绍检索增强生成（RAG）技术如何通过结合实时数据检索与AI生成能力解决专业领域问题，并推荐10个实用项目： CodeWhisperer：开发者文档智能问答助手； LegalEagle：法律合同解析机器人； MediGuru：基于医学文献的问答系统； LearnBot：个性化教育辅导工具； NewsDigest：新闻摘要生成器； TripPlanner：动态旅行行程规划系统。 每个项目均提供技术栈选型、实现流程和扩展方向，涵盖
别背八股文了，WebSocket 是什么，我劝你花几分钟让面试官惊艳！
前端原创分享，常年坚持记录和分享，全网阅读量超百万
07-18 1181
作为前端工程师，我们几乎每天都在使用 ajax / fetch 请求与后端进行数据交互，这种基于请求-响应的通讯模式，我们再熟练不过了，无论是C端产品或者是B端产品，都离不开这种通讯模式。但是像即时通讯IM类场景，通常不会选择这种“你来我回”的通信模式，而是会选择 WebSocket 这类的全双工通信模式。本文会带您全方位去了解一下 WebSocket 的本质，方便您搞清楚“Connection: Upgrade 是什么意思，为什么是它？”、“Upgrade: WebSocket 又是什么意思？
rocket消息队列失败从试时间间隔_上海财经大学：消息中心点亮智慧校园
weixin_39655160的博客
10-22 236
高校智慧校园建设旨在改变师生与学校资源、环境的交互方式，开展以人为本的个性化服务，进而建立智能开放的教育环境和便利舒适的生活环境。消息中心服务可以将各类业务过程中产生的消息进行集中管理与收发，师生用户可以方便、及时、准确的获知个人所关注的各类业务状态，实现了学校消息的一站式与个性化推送。因此，消息中心成为高校智慧校园建设的一项重要内容。消息中心的实现依赖于高效可靠的消息队列中间件(简称消...
消息已读未读功能如何系统设计？
weixin_46072507的博客
05-02 809
IM系统（如微信、钉钉、飞书）评论通知（如微博、知乎）系统消息/站内信电商站内通知。
[译] 为 APP 设计通知提醒
weixin_34248705的博客
09-20 411
原文地址：Designing notifications for apps: Explore different notification models and when to use which 原文作者：Shashank Sahay 译文出自：掘金翻译计划 本文永久链接：github.com/xitu/gold-m… 译者：Ryden Sun 校对者：pkuwwt sanfran1068...
消息已读未读的模型设计_构建一个即时消息应用（三）：对话 | Linux 中国
weixin_39628256的博客
12-01 525
在我们的即时消息应用中，消息表现为两个参与者对话的堆叠。-- Nicolás Parada本文是该系列的第三篇。◈第一篇：模式◈第二篇：OAuth在我们的即时消息应用中，消息表现为两个参与者对话的堆叠。如果你想要开始一场对话，就应该向应用提供你想要交谈的用户，而当对话创建后(如果该对话此前并不存在)，就可以向该对话发送消息。就前端而言，我们可能想要显示一份近期对话列表。并在此处显示对...
【小程序开发日志②】关注后消息推送已读/未读的数据库+后端设计
jeason_L的博客
03-15 3721
上述是应用场景，但经过构思这样供应商关注量大的话，按这样思路可能会使服务器爆炸。然后就问大佬，大佬说只在需求方读一条数据的时候才插入数据，消息的已读未读状态可以通过需求表left join到需求通知状态表，判断已读，其他便是未读的了，如果发送小程序提醒或公众号提醒就通过异步(必要时需要用到队列redis)，只要需求发布了，就推一条给异步，让异步遍历后发送就好了。 ——大佬终归是大佬 ...
Android 通知设置
tq501501的博客
10-22 1717
写在前面，8.0以后的通知写法如下 Android 8.0中各种通知写法汇总 最终通过NotificationManager.notify()发送通知。 1、通知发送流程 相关类 frameworks/base/core/java/android/app/NotificationManager.java frameworks/base/services/core/java/com/android/server/notification/NotificationManagerService..
消息数据表设计
qq_40484634的博客
08-25 7091
消息数据表设计 消息一般分为 通告（公告） 消息（站内短信） 提醒 通告（bulletin） 通告是平台发，用户收，通告分为实时和非实时 ，通告有优先级：紧急，高，普通。 平台可以向一个用户、多个用户、指定的群体、全部用户发送通告 通告发布后，一般不会修改。 表设计 通告表 id 主键自增 level 优先级 create_time 发布时间戳 delete_time 删除时间戳，不为0表示删除 默认0 title 标题 content 内容 cancel_ti
消息已读未读的模型设计_现代IM系统中的消息系统架构
专注Java（全栈）应用开发，求知若渴，虚心若愚，talk is cheap, show me the code.
03-13 486
消息已读未读的模型设计_现代IM系统中的消息系统架构。
ucos移植小结1
largon10的博客
09-30 514
1、ucos首次移植时，需将PendSVHandler替换为OS_CPU_PendSVHandler，将SysTickHandler替换为OS_CPU_SysTickHandler，另外需要将步骤二中stm32f10x_it.c中的这两个中断服务函数注释掉，而使用uCOS-III中的这两个中断服务函数。 ...
群聊系统中，未读消息和已读消息应该怎么设计
05-10
<think>好的，我现在需要帮用户设计群聊系统中未读消息和已读消息的方案。首先，用户提到了参考的引用内容，里面有提到读扩散和写扩散的模式，还有消息存储模型。我得先理清楚这些概念。 首先，用户的问题是关于群聊的已读未读功能，发送者发消息后，群成员显示未读，当有人阅读后，状态更新。需要高效存储和查询。根据引用[4]，读扩散和写扩散的区别在于消息的存储方式。读扩散是每个会话保存全量消息，接收端拉取时需要检查每个会话，适合消息量少的情况。而写扩散则是每个用户有自己的消息队列，消息会被复制到每个成员的队列中，适合群聊这种场景，因为可以快速标记已读，但存储压力大。 接下来，用户需要具体的设计方案。我需要分步骤来考虑：存储模型、已读标记、实时同步、性能优化。 存储模型方面，引用[3]提到消息按会话存储，每个会话有一个Timeline，消息有序排列。可能需要在消息表中记录每条消息的基本信息，比如message_id、group_id、sender_id、content、timestamp等。然后已读状态可能需要单独的表，记录用户、消息ID和已读状态，比如message_read_status表，包含user_id、message_id、read_time等字段。不过群聊成员可能很多，如果每个消息都记录所有成员的已读状态，数据量会爆炸，需要考虑优化。 这时候想到引用[4]中的写扩散，可能更适合群聊。因为每个用户有自己的未读消息队列，当用户读取后，只需在自己的队列中标记已读，这样更新效率高。但存储成本会增加，因为每个消息要复制到所有成员的队列中。不过对于活跃的群聊来说，这可能更高效。 然后是已读标记的同步。当用户读取消息时，需要更新状态，并通知其他用户。可以考虑使用消息队列或者发布订阅机制，比如Kafka，来实时推送状态变更。这样发送者能及时看到已读人数的变化。 性能优化方面，分库分表可能有必要，比如按group_id或user_id分片，减少单表压力。另外，对于大群，比如万人群，逐个记录已读状态可能不现实，可以采用位图或者布隆过滤器来压缩存储。例如，每个消息对应一个位图，每一位代表一个用户是否已读，这样存储空间节省很多。但位图可能需要预先知道用户数量，或者动态扩展，这需要设计好。 另外，冷热数据分离也很重要。最近的未读消息保持高效访问，而历史数据可以归档，减少实时库的压力。缓存方面，使用Redis存储最近的已读状态，加快查询速度。比如用Hash结构存message_id和已读用户数，或者用Set存已读的用户ID，但要注意缓存和数据库的一致性。 还需要考虑查询已读未读列表的效率。如果用户点击消息详情，需要快速列出已读和未读的用户。这时候如果使用位图，可能需要遍历位图，但效率可能不高。或者维护两个列表，已读和未读，但更新时需要同时维护这两个列表，可能会复杂一些。或许可以结合数据库和缓存，实时查询时从缓存获取，同时异步更新数据库。 另外，消息的扩散方式会影响设计。写扩散虽然存储成本高，但查询和更新已读状态更快，因为每个用户的消息队列独立。而读扩散可能需要每次拉取所有会话的消息，但存储成本低。这里需要根据群聊的活跃度和规模来权衡。例如，小群用写扩散，大群用读扩散结合位图。 还有，消息的唯一性很重要，每个消息有唯一的message_id，确保在全局不会重复。用户ID也是唯一的，这样在记录已读状态时不会有冲突。 最后，需要考虑系统的扩展性和可靠性。比如，分片策略是否允许水平扩展，消息队列的吞吐量是否足够，以及如何处理故障恢复，确保已读状态不会丢失。 总结一下，设计方案需要包括存储模型的选择（写扩散或读扩散），已读状态的存储方式（位图、单独的表），实时同步机制，分库分表和缓存策略，以及针对大群的优化措施如位图压缩。同时，引用中提到的读扩散和写扩散的优缺点需要综合考虑，选择适合群聊场景的方案。</think>### 群聊系统未读消息与已读消息设计方案 #### 一、核心设计原则 1. **高效存储**：支持高并发读写，避免单点瓶颈[^4] 2. **实时同步**：消息状态变更需在秒级内同步到所有客户端 3. **查询优化**：快速响应消息的已读未读人数统计和明细查询 4. **可扩展性**：支持万人级大群场景 #### 二、详细设计方案 ##### 1. 存储模型设计 **(1) 消息主表** ```sql CREATE TABLE messages ( message_id BIGINT PRIMARY KEY, -- 全局唯一消息ID group_id BIGINT NOT NULL, -- 群ID sender_id BIGINT NOT NULL, -- 发送者ID content TEXT, -- 消息内容 create_time DATETIME -- 发送时间 ) ``` **(2) 已读状态存储（写扩散模式）** 采用BitMap压缩存储，每个消息对应一个BitMap： ```sql CREATE TABLE read_status ( message_id BIGINT PRIMARY KEY, group_id BIGINT NOT NULL, bitmap BLOB, -- 压缩位图(每位代表一个用户) version INT -- 乐观锁版本 ) ``` *示例：1万人群仅需1.25KB存储空间* *优势：空间效率高，支持快速统计已读人数*[^4] **(3) 未读队列（写扩散模式）** 每个用户维护未读消息队列： ```python # Redis存储结构样例 user_unread:{ "user:1001": sorted_set( "group:2001": [message_id1, message_id2...], "group:2002": [message_id3, message_id4...] ) } ``` ##### 2. 核心流程实现 **消息发送流程** ```mermaid sequenceDiagram participant 发送者 participant 服务端 participant Redis participant DB 发送者->>服务端: 发送群消息 服务端->>DB: 写入消息主表 服务端->>Redis: 为每个群成员添加未读标记 服务端->>服务端: 生成初始全0位图 DB-->>服务端: 返回消息ID 服务端->>发送者: 返回发送成功 ``` **消息已读标记流程** ```python def mark_as_read(user_id, message_id): # 原子操作更新位图 execute( "UPDATE read_status SET bitmap = SET_BIT(bitmap, ?, 1) WHERE message_id = ?", user_id, message_id ) # 删除未读队列记录 redis.zrem(f"user_unread:{user_id}", message_id) # 发布状态变更事件 kafka.publish("read_event", {"message_id": message_id, "user_id": user_id}) ``` ##### 3. 性能优化策略 1. **分层存储** - 热数据：Redis存储最近7天未读队列 - 冷数据：MySQL归档三个月前记录 2. **批量处理** ```sql -- 批量标记已读 UPDATE read_status SET bitmap = bitmap | b'...' WHERE message_id IN (...) ``` 3. **读写分离** - 写操作：主库处理状态变更 - 读操作：从库响应统计查询 #### 三、特殊场景处理 1. **新成员入群** - 增量同步：仅同步入群后产生的消息 - 历史消息：通过位图特殊标记"无需阅读" 2. **万人群优化** - 分片存储：按user_id范围分片存储位图 - 异步统计：定时任务预计算已读人数 3. **消息撤回** - 级联删除：同时清理所有关联状态记录 - 事务补偿：采用Saga模式保证一致性 #### 四、监控指标 1. 状态更新延迟(P99 < 200ms) 2. 未读队列同步成功率(>99.99%) 3. 位图存储压缩率(目标85%+)
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值