仿小红书源码实战：消息通知与未读数系统的设计与实现

在内容型社区产品里有一个很容易被低估的模块消息通知系统。很多项目在早期阶段更关注信息流、发布能力或互动功能本身但随着用户逐渐活跃一个现象会变得越来越明显——用户是否能及时感知到“被互动”直接决定了活跃度的上限。比如发布内容后有没有人点赞评论是否被回复是否有新的关注者如果这些反馈没有被有效传递再完善的功能也难以形成持续使用。因此从工程角度来看消息通知系统不仅是功能补充更是连接用户行为与用户感知的关键环节。一、消息系统的本质事件驱动所有通知的本质都来源于“用户行为事件”点赞 → 触发点赞通知评论 → 触发评论通知关注 → 触发关注通知因此第一步不是设计消息表而是构建事件模型常见做法行为发生 → 发送事件消息模块订阅 → 生成通知二、消息分类设计避免结构混乱在实际项目中消息通常分为三类1. 系统通知官方公告系统提醒2. 互动通知点赞评论关注3. 私信消息用户之间聊天IM 前两类属于“通知系统”第三类属于“通讯系统”需要分开设计。三、消息存储结构设计一个典型的通知表结构会包含消息ID接收用户ID触发用户ID消息类型关联业务ID如postId状态已读/未读创建时间设计要点支持扩展不同类型消息支持快速查询按用户分页四、未读数系统性能关键点未读数是一个高频读取数据每次进入首页都会请求每个用户都有独立数据如果每次都查数据库统计会带来严重性能问题。 正确方式是使用缓存维护未读数未读数缓存设计Keymsg:unread:{userId}Value未读数量示例实现// 新消息产生时增加未读数 String key msg:unread: userId; redisTemplate.opsForValue().increment(key); 用户读取消息后 // 用户查看消息后清零 redisTemplate.delete(msg:unread: userId);这样可以实现O(1) 获取未读数避免频繁统计数据库五、消息列表获取分页与缓存消息列表通常按时间倒序分页最新消息优先支持分页加载优化方式热数据缓存最近消息冷数据走数据库 可以采用“缓存 数据库”组合模式。六、去重与合并提升用户体验在实际场景中如果不做处理用户可能会看到“A点赞了你”“B点赞了你”“C点赞了你”连续多条通知体验较差。优化方式消息合并例如“3人点赞了你”“5人评论了你”实现方式同类型消息聚合Redis中临时合并或前端聚合展示七、与IM系统的关系很多人会混淆通知系统IM系统两者区别类型特点通知异步、弱实时IM实时、双向通信但在工程上可以结合IM用于实时提醒Redis用于未读数数据库存储历史消息八、多端同步问题在四端统一架构下APP、小程序、H5需要解决未读数同步问题例如用户在APP读了消息小程序是否同步解决方案所有状态写入服务端客户端不做本地判断每次进入页面刷新未读数九、常见问题与优化1. 未读数不准确使用原子操作Redis INCR2. 消息丢失事件 持久化双保险3. 消息过多分表或归档历史数据4. 性能瓶颈热数据缓存异步处理十、总结消息通知系统往往不被重视但它直接影响用户是否“感知到互动”。换一种更贴近产品的理解用户不是因为有内容而活跃而是因为“被互动”而活跃。从工程角度来看通知系统负责“触达”未读数系统负责“提醒”IM系统负责“实时互动”当这三者协同工作时一个内容社区的活跃度才会真正被激发。⭐⭐作为成熟的宠友社区相关资料与源码均已放在官网⭐⭐https://www.chongyou.info/1/product/xhs.html