消息与通信类场景题
概述
消息与通信类场景题考察即时通讯、消息推送、实时交互等能力。这类题目涉及长连接管理、消息可靠传输、高并发推送等核心技术。
核心知识点
即时通讯
- 长连接管理（WebSocket、TCP）
- 消息存储和同步
- 离线消息处理
- 已读回执机制
消息推送
- 推送通道选择
- 多端同步
- 优先级队列
- 到达率保证
实时交互
- 弹幕处理
- 实时通知
- 在线状态管理
- 连接保活
题目列表
⭐ 如何设计消息推送系统 🆕
难度: 中级
标签: APNs、FCM、长连接、离线消息
考察点: 推送架构、消息可达性、长连接管理
消息推送系统用于向移动端设备推送消息通知，需要对接APNs、FCM等第三方推送服务，保证消息的高可达率。
核心难点:
- APNs和FCM如何接入？
- 如何提高消息到达率？
- 长连接如何保活？
- 离线消息如何存储？
技术栈: APNs、FCM、WebSocket、Redis
⭐ 如何设计弹幕系统 🆕
难度: 中级
标签: WebSocket、实时推送、轨道分配
考察点: 弹幕存储、实时推送、碰撞检测、敏感词过滤
弹幕系统需要实时推送用户评论，处理高并发发送，实现弹幕轨道分配防止碰撞。
核心难点:
- 弹幕如何存储和查询？
- 如何实时推送给观看用户？
- 弹幕轨道如何分配（防碰撞）？
- 如何过滤敏感词？
技术栈: MongoDB、Redis、WebSocket、DFA算法
⭐ 如何设计IM即时通讯系统
难度: 专家
标签: WebSocket、长连接、消息存储
考察点: 长连接管理、消息可靠性、群聊优化
IM系统是最复杂的实时通信系统，涉及单聊、群聊、离线消息、多端同步等多个场景。
核心难点:
- 如何管理海量长连接？
- 如何保证消息不丢失？
- 如何优化群聊性能？
- 如何实现多端同步？
技术方案:
- WebSocket长连接
- 消息存储（MongoDB、MySQL）
- 消息队列（Kafka）
- 多端同步策略
相关技术栈:
如何设计消息推送系统
难度: 高级
标签: 推送通道、多端同步、优先级
考察点: 推送可靠性、到达率、性能优化
消息推送系统需要支持App推送、短信、邮件等多种通道，保证高到达率。
核心难点:
- 如何选择推送通道？
- 如何提高到达率？
- 如何处理推送失败？
- 如何实现优先级推送？
技术方案:
- APNs、FCM（移动推送）
- WebSocket（Web推送）
- 优先级队列
- 失败重试机制
相关技术栈:
如何设计弹幕系统
难度: 高级
标签: 实时分发、防刷、敏感词
考察点: 高并发推送、过滤机制
弹幕系统需要处理百万级并发用户的实时弹幕发送和接收。
核心难点:
- 如何实时分发弹幕？
- 如何防止弹幕刷屏？
- 如何过滤敏感词？
- 如何处理弹幕碰撞？
技术方案:
- WebSocket群发
- 敏感词过滤（DFA算法）
- 限流防刷
- 弹幕碰撞检测
相关技术栈:
如何设计通知中心
难度: 中级
标签: 消息聚合、模板引擎、多渠道
考察点: 消息分类、模板管理、发送策略
通知中心统一管理系统内所有通知消息，支持多种发送渠道。
核心难点:
- 如何统一管理通知？
- 如何支持多种模板？
- 如何选择发送渠道？
- 如何保证发送成功？
技术方案:
- 消息分类和优先级
- 模板引擎
- 多渠道发送
- 失败重试
相关技术栈:
如何设计邮件系统
难度: 中级
标签: SMTP、队列、反垃圾
考察点: 批量发送、失败处理、反垃圾
邮件系统需要支持大批量邮件发送，保证发送成功率，防止被识别为垃圾邮件。
核心难点:
- 如何提高发送成功率？
- 如何防止被识别为垃圾邮件？
- 如何处理退信？
- 如何统计发送效果？
技术方案:
- SMTP协议
- 邮件队列
- SPF、DKIM、DMARC
- 退信处理
相关技术栈:
- 消息队列 - 邮件队列
学习路径
初学者（P5-P6）
推荐顺序：
- 通知中心 → 理解消息分类
- 邮件系统 → 学习SMTP协议
- 简单的聊天室 → 理解WebSocket
进阶者（P6-P7）
推荐顺序：
- 消息推送系统 → 掌握推送技术
- 弹幕系统 → 学习实时分发
- 简单的IM系统 → 理解消息存储
高级工程师（P7-P8）
推荐顺序：
- 完整的IM系统 → 掌握全链路
- 大规模推送系统 → 性能优化
- 实时音视频 → RTC技术
技术要点总结
长连接vs短连接
| 维度 | 长连接 | 短连接 |
|---|---|---|
| 适用场景 | IM、推送、实时游戏 | HTTP请求 |
| 资源占用 | 高 | 低 |
| 实时性 | 高 | 低 |
| 复杂度 | 高 | 低 |
消息可靠性保证
| 级别 | 方案 | 应用场景 |
|---|---|---|
| At Most Once | 尽力而为，不保证 | 弹幕、在线状态 |
| At Least Once | 重试机制，可能重复 | 推送通知 |
| Exactly Once | 幂等+去重，保证一次 | 支付、订单 |
IM消息存储方案
| 方案 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| MySQL | 可靠、支持事务 | 性能一般 | 重要消息 |
| MongoDB | 高性能、灵活 | 无事务 | 普通消息 |
| HBase | 海量存储 | 查询受限 | 历史消息 |
| Redis | 极高性能 | 易丢失 | 临时消息 |
常见问题
Q: 长连接如何保活？
A:
- 心跳机制：客户端定期发送心跳（如30秒）
- 超时检测：服务端超时未收到心跳则断开
- 断线重连：客户端检测断开后自动重连
- 指数退避：重连失败时逐步增加间隔
Q: 如何实现消息已读未读？
A:
- 单聊已读：接收方阅读后发送已读回执
- 群聊已读：每个人的已读状态独立存储
- 已读水位：记录每个会话的已读消息ID
- 未读数统计：总消息数 - 已读水位
Q: 群聊如何优化性能？
A:
- 消息扩散：发送时复制N份（适合小群）
- 读扩散：存储一份，读取时查询（适合大群）
- 混合模式：小群写扩散，大群读扩散
- 离线消息：只推送@我的和最新N条
相关技术栈
面试技巧
回答框架
需求澄清（2分钟）
- 用户规模
- 消息类型
- 实时性要求
架构设计（10分钟）
- 连接管理
- 消息存储
- 消息分发
- 多端同步
技术细节（8分钟）
- 心跳保活
- 消息可靠性
- 性能优化
- 监控告警
扩展讨论（5分钟）
- 如何扩展到百万在线
- 如何保证消息不丢
- 如何优化流量消耗
常见追问
- 如何实现消息必达？
- 如何处理消息风暴？
- 如何实现端到端加密？
- 如何优化消息存储成本？
提示：消息通信题重在理解实时性和可靠性的权衡。不同场景对可靠性要求不同，要能根据场景选择合适的方案。IM系统是最复杂的，建议重点准备。