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

最新推荐文章于 2024-07-11 20:17:45 发布
最新推荐文章于 2024-07-11 20:17:45 发布
阅读量350 收藏
点赞数
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中实现这一方案，以降低存储成本并提高效率。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

企业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 1157
《知识付费：程序员的社群运营思维》 关键词： 知识付费、程序员、社群运营、用户需求、互动交流、数据分析 摘要： 本文旨在探讨知识付费背景下，程序员如何通过社群运营提升自
【2025跑通的AI变现玩法之四】【AI+口播视频小红书掘金指南：从0到3万粉的实战方法论】
最新发布
商务合作|问题讨论|交流学习 请联系作者微信，加微信请务必注明来意，博客主页有联系方式
04-18 1651
通过矩阵化账号布局、AI驱动的内容生产、数据化的流量运营，普通人完全可以在3-6个月内打造出月入过万的知识型博主账号。建议运营者保持对平台规则和技术趋势的敏感度，不断迭代优化，在小红书这片内容电商的蓝海中持续掘金。的模式，在8个月内实现3万粉丝增长，单月带货佣金超2万元。未来，随着AI技术的进一步发展，内容创作的门槛将持续降低，而。的组合拳，可实现从文案生成到视频制作的全流程自动化。在内容电商爆发的2025年，小红书已成为。AI+口播视频项目在小红书的落地，本质是。的生活方式社区，用户群体呈现。
面试官：群聊消息的已读未读功能，你来设计一个?
superjava_的博客
12-30 379
一朋友和我讨论他前段时间面试某大公司的一题目 ： 企业IM比如企业微信、钉钉里面的群消息的有个已读未读的功能，发送者刚发出消息时，当前群里其他群成员都是未读状态，陆陆续续有人看了这个消息，这时候消息的详情变成x人已读，y人未读，如下图所示，有具体的已读未读列表（万恶的功能，看到同事or老板的消息不能假装没看到了），每条消息对应一个唯一的messageid（uint64_t），每个用户对应一个唯一的userid（uint64_t）,应该如何保存这个消息对应的已读未读详情呢？ 图片 我第一时间给出
头条面试官：如何设计群聊消息的已读未读功能
hello world！
10-27 632
点击上方蓝色“java大数据修炼之道”,选择“设为星标” 每晚九点: 技术干货 ???? 必定奉上来源：toutiao.com/i6686735232772604429一朋友和我讨论他前段时间...
这样设计群聊消息的已读未读功能，领导给我发了奖金
程序员小乐
03-02 480
????推荐大家关注一个公众号????点击上方 "编程技术圈"关注,星标或置顶一起成长后台回复“大礼包”有惊喜礼包！每日英文Some troubles are made up by ourselve...
rocket消息队列失败从试时间间隔_上海财经大学：消息中心点亮智慧校园
weixin_39655160的博客
10-22 215
高校智慧校园建设旨在改变师生与学校资源、环境的交互方式，开展以人为本的个性化服务，进而建立智能开放的教育环境和便利舒适的生活环境。消息中心服务可以将各类业务过程中产生的消息进行集中管理与收发，师生用户可以方便、及时、准确的获知个人所关注的各类业务状态，实现了学校消息的一站式与个性化推送。因此，消息中心成为高校智慧校园建设的一项重要内容。消息中心的实现依赖于高效可靠的消息队列中间件(简称消...
数据结构面试--如何设计群聊消息的已读未读功能
dazhong2012的专栏
04-29 1578
在企业即时通讯(IM)软件中，如企业微信、钉钉等，群聊消息的已读未读功能是一个重要的特性。它不仅帮助用户了解哪些消息已经被阅读，还能促进信息的及时反馈和处理。在设计这一功能时，我们需要考虑存储效率、系统性能以及用户体验等多个方面。本文将探讨如何设计一个高效且实用的群聊消息已读未读系统。
【读书笔记】《深度神经网络FPGA设计与实现》（孙其功）第二章 深度学习开发平台
qq_45355365的博客
07-11 1190
《深度神经网络FPGA设计与实现》读书笔记
app里未读消息已读、未读是怎么设计的？
关注我！带你一路 "狂飙" 到底！
03-03 4669
一款app，消息页面有：钱包通知、最近访客等各种通知类别，每个类别可能有新的通知消息，实现已读、未读功能，包括多少个未读，这个是怎么实现的呢？比如用户A访问了用户B的主页，难道用rabitmq给B发通知消息吗？量大了成本受得了吗？有没有成本低的方案呢
[译] 为 APP 设计通知提醒
weixin_34248705的博客
09-20 393
原文地址：Designing notifications for apps: Explore different notification models and when to use which 原文作者：Shashank Sahay 译文出自：掘金翻译计划 本文永久链接：github.com/xitu/gold-m… 译者：Ryden Sun 校对者：pkuwwt sanfran1068...
消息推送中的已读消息和未读消息设计难题
qq_63431773的博客
11-16 2177
站内信”有两个基本功能：用户给用户发送站内信，管理员给用户发送站内信。管理员给用户（指定满足某一条件的用户群）群发消息这两个功能实现起来也很简单｛如图｝。只需要设计一个消息内容表和一个用户通知表，当创建一条系统通知后，数据插入到消息内容表。消息内容包含了发送渠道，根据发送渠道决定后续动作。如果是站内渠道，在插入消息内容后异步的插入记录到用户通知表。这个方案看起来没什么问题，但实际上，我们把所有用户通知的消息全部放在一个表里面，如果有 10W 个用户，那么同样的消息需要存储 10W 条。
消息已读未读的模型设计_构建一个即时消息应用（三）：对话 | Linux 中国
weixin_39628256的博客
12-01 492
在我们的即时消息应用中，消息表现为两个参与者对话的堆叠。-- Nicolás Parada本文是该系列的第三篇。◈第一篇：模式◈第二篇：OAuth在我们的即时消息应用中，消息表现为两个参与者对话的堆叠。如果你想要开始一场对话，就应该向应用提供你想要交谈的用户，而当对话创建后(如果该对话此前并不存在)，就可以向该对话发送消息。就前端而言，我们可能想要显示一份近期对话列表。并在此处显示对...
【小程序开发日志②】关注后消息推送已读/未读的数据库+后端设计
jeason_L的博客
03-15 3684
上述是应用场景，但经过构思这样供应商关注量大的话，按这样思路可能会使服务器爆炸。然后就问大佬，大佬说只在需求方读一条数据的时候才插入数据，消息的已读未读状态可以通过需求表left join到需求通知状态表，判断已读，其他便是未读的了，如果发送小程序提醒或公众号提醒就通过异步(必要时需要用到队列redis)，只要需求发布了，就推一条给异步，让异步遍历后发送就好了。 ——大佬终归是大佬 ...
Android 通知设置
tq501501的博客
10-22 1651
写在前面，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 6957
消息数据表设计 消息一般分为 通告（公告） 消息（站内短信） 提醒 通告（bulletin） 通告是平台发，用户收，通告分为实时和非实时 ，通告有优先级：紧急，高，普通。 平台可以向一个用户、多个用户、指定的群体、全部用户发送通告 通告发布后，一般不会修改。 表设计 通告表 id 主键自增 level 优先级 create_time 发布时间戳 delete_time 删除时间戳，不为0表示删除 默认0 title 标题 content 内容 cancel_ti
消息已读未读的模型设计_现代IM系统中的消息系统架构
专注Java（全栈）应用开发，求知若渴，虚心若愚，talk is cheap, show me the code.
03-13 460
消息已读未读的模型设计_现代IM系统中的消息系统架构。
ucos移植小结1
largon10的博客
09-30 482
1、ucos首次移植时，需将PendSVHandler替换为OS_CPU_PendSVHandler，将SysTickHandler替换为OS_CPU_SysTickHandler，另外需要将步骤二中stm32f10x_it.c中的这两个中断服务函数注释掉，而使用uCOS-III中的这两个中断服务函数。 ...
Web聊天室消息[已读未读]的实现
shellhard的博客
07-12 8114
聊天室快速访问 继上次完成聊天室的历史记录功能后，我又想着实现聊天记录的已读未读功能。（轻喷。。） 开始之前 首先我看了抖音和钉钉这两款应用的消息已读未读功能的呈现效果。首先是抖音，在聊天界面，给好友发送完消息后，消息界面的最右下角有一个“已发送”标记，这时候是属于对方未读，如果对方上线并别点开了和你的聊天界面，你和他的聊天界面上，那个“已发送”就变成了“已读”，所以抖音并不会每一条消息上面都显示“已读”或者“未读”。而钉钉，由于其专注于办公，这个已读未读功能就“变态”多了，每一条发出去的消息都会显示对方是
websocket消息已读未读实现功能
03-28
<think>好的，我现在需要帮助用户实现WebSocket消息的已读和未读功能。首先，我得理解用户的需求。用户可能正在开发一个实时通讯应用，比如聊天室或者即时消息系统，需要跟踪哪些消息已经被用户阅读，哪些还没有。这功能对于用户体验很重要，尤其是在群聊或者有多个对话的场景中。 接下来，我得回忆一下WebSocket的基本机制。WebSocket提供了全双工通信，适合实时应用。但WebSocket本身并不处理消息状态，所以需要自己设计实现。用户提到的已读和未读状态，可能需要结合客户端和服务端的协作。 根据用户提供的引用资料，特别是引用[3]，里面提到使用status参数来区分消息状态。服务器返回消息列表时，status为1表示已读，0未读。当用户查看消息时，客户端需要发送已读回执给服务器，更新状态。这应该是核心思路。 我需要考虑几个方面： 1. **消息结构设计**：消息对象需要包含状态字段，比如status或者readStatus，可能还需要时间戳、发送者、接收者等信息。例如： $$ \text{消息对象} = \{ \text{id: string, content: string, sender: string, receiver: string, status: 0|1, timestamp: number} \} $$ 这样设计可以在服务端存储每个消息的状态。 2. **已读回执机制**：当用户打开聊天窗口或滚动到消息位置时，客户端发送已读确认。例如，发送一个包含消息ID和用户ID的WebSocket消息到服务器，服务器更新这些消息的状态为已读。引用[3]中的例子是通过currentMessage设置status为0，可能是在进入聊天时标记为已读。 3. **未读计数**：客户端需要根据消息状态统计未读数量。服务端在用户登录或重连时推送未读消息列表。这需要维护每个用户的消息队列，并过滤status为0的消息。例如，用户A登录后，服务端查询所有receiver是A且status=0的消息，推送给客户端，并更新未读计数。 4. **数据存储**：消息状态需要持久化存储，所以服务端可能需要使用数据库，比如MongoDB或MySQL。每次收到已读回执，更新数据库中对应消息的状态。引用[1]提到使用RabbitMQ搭建，可能涉及消息队列处理，但这里可能直接用数据库更简单。 5. **实时同步**：当一条消息被标记为已读，其他在线用户是否需要实时更新？比如在群聊中，当某个用户阅读了消息，其他人是否能看到该消息的状态变化。这可能需要服务端主动推送状态更新给所有相关客户端。 6. **离线处理**：用户离线时收到的消息，在下次上线时需要拉取未读消息。服务端需要记录用户的最后在线时间，或者在用户登录时查询所有未读消息。 可能的挑战包括如何高效地更新大量消息的状态，比如用户快速滚动浏览历史消息时，如何批量发送已读回执，避免频繁的网络请求。另外，处理并发情况，比如多个设备同时标记同一条消息为已读，需要保证数据一致性。 参考引用[2]和[3]，使用Node.js和WebSocket实现的话，可以在服务端维护一个消息存储，当客户端发送已读指令时，更新对应的消息状态。例如，客户端发送： ```json { "type": "mark_as_read", "messageIds": ["msg1", "msg2"], "userId": "user123" } ``` 服务端收到后，在数据库中将这些消息的status字段更新为1，并可能广播给其他相关客户端（如果需要）。 此外，未读计数的维护可以在客户端本地进行，每次接收到新消息时，如果当前聊天窗口是打开的，则自动标记为已读，否则增加未读计数。当用户切换到该聊天时，发送已读回执并更新计数。 需要测试不同场景，比如网络延迟、消息重复发送、客户端异常断开等情况，确保状态同步的准确性。可能还需要考虑消息的时序，避免因消息到达顺序问题导致状态错误。 总结下来，步骤大致是： - 设计消息结构，包含状态字段。 - 客户端在适当的时候发送已读回执。 - 服务端更新数据库并同步状态。 - 客户端根据状态显示未读计数。 - 处理离线和多设备的情况。</think>### 分步实现WebSocket消息已读/未读功能 #### 1. 消息结构设计（服务端） 在数据库和通信协议中定义消息必须包含状态标识： ```javascript { id: "消息唯一ID", content: "消息内容", sender: "发送者ID", receiver: "接收者ID/群ID", status: 0, // 0未读 1已读 timestamp: 1672531200000 } ``` 使用MongoDB时可创建消息集合： ```javascript db.messages.createIndex({ receiver: 1, status: 1 }) // 加速查询 ``` #### 2. 未读消息推送（服务端） 用户建立WebSocket连接时推送未读消息： ```python # Python伪代码示例 async def on_connect(user_id): unread = db.messages.find({ "receiver": user_id, "status": 0 }) await websocket.send(json.dumps({ "type": "initial_unread", "data": list(unread) })) ``` #### 3. 实时消息处理流程 ```mermaid sequenceDiagram participant A as 客户端A participant S as 服务端 participant B as 客户端B A->>S: 发送消息{id:123,status:0} S->>B: 推送新消息(带未读状态) S->>S: 持久化到数据库 B->>S: 阅读后发送已读回执{msgId:123} S->>S: 更新消息状态为已读 S->>A: 推送状态更新通知 ``` #### 4. 已读回执实现（客户端） ```javascript // 监听可视区域变化 const observer = new IntersectionObserver(entries => { entries.forEach(entry => { if (entry.isIntersecting) { const msgId = entry.target.dataset.id; ws.send(JSON.stringify({ type: 'mark_read', messageIds: [msgId] })); } }); }); // 绑定消息DOM元素 document.querySelectorAll('.message').forEach(el => { observer.observe(el); }); ``` #### 5. 未读计数优化方案 $$ \text{未读数} = \sum_{i=1}^{n} \begin{cases} 1 & \text{当 } status_i=0 \text{ 且 } \neg isActiveChat \\ 0 & \text{其他情况} \end{cases} $$ 使用Redis维护实时计数器： ```python def update_unread_count(user_id, delta): redis.incrby(f'unread:{user_id}', delta) # 设置过期时间防止内存泄漏 redis.expire(f'unread:{user_id}', 86400) ``` #### 6. 异常情况处理 - 消息去重：为每条消息添加UUID - 离线补偿：记录最后接收消息时间戳 - 状态同步：定期全量同步（每日1次） ```javascript // 客户端重连时检查 ws.addEventListener('open', () => { if (lastReceivedTime < Date.now() - 60000) { requestFullSync(); } }); ```
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值