Java消息通知系统围绕“谁发、发给谁、怎么发、如何查、能否撤”五动作构建,通过接口抽象+策略模式实现通道解耦,分层建模状态与模板,用Redis计数未读,MQ+WebSocket保障撤回与多端同步。

Java构建消息通知系统,核心在于解耦通知行为与业务逻辑,同时兼顾可扩展性、实时性和一致性。不是堆功能,而是围绕“谁发、发给谁、怎么发、如何查、能否撤”这五个关键动作来组织架构。
明确通知的触发来源和接收范围
通知必须分清发起方和作用域:
- App用户操作触发(如评论回复、点赞、关注),目标是特定用户或关系链中的若干人
- 管理后台主动下发(如活动公告、系统升级提醒),支持单发、按部门、按角色、全量推送
- 外部系统集成(如订单中心、风控平台)通过接口投递事件,需统一接入网关并做幂等校验
设计轻量但可插拔的通知通道
避免硬编码邮件、短信、站内信逻辑。推荐基于接口抽象 + 策略模式实现:
- 定义NotificationService接口,含send(Message message)方法
- 为每种渠道实现子类:EmailNotificationService、SmsNotificationService、PushNotificationService(对接极光/个推)、InAppNotificationService(写入数据库)
- 用工厂或Spring @Qualifier动态选择通道,例如根据用户偏好配置或消息优先级自动降级
保障消息状态可追踪、可回溯
真实业务中,“已发送 ≠ 已触达 ≠ 已阅读”,需分层建模:
立即学习“Java免费学习笔记(深入)”;
- notification表存主记录:id、sender_id、receiver_id、type(COMMENT_REPLY/ACTIVITY_NOTICE)、content、status(SENT/READ/REVOKED)、created_at、updated_at
- 加notification_config表管理模板:title、body、跳转url、是否允许撤回、有效期
- 未读数用Redis原子计数器(如user:1001:unread_count),增删同步更新,避免每次查库统计
支持撤回与多端状态同步
撤回不是删除数据,而是状态变更,且要影响所有终端:
- 撤回操作更新notification.status = REVOKED,并广播MQ事件
- WebSocket服务监听该事件,向在线用户推送“已撤回”指令,前端清除红点、灰化条目
- 离线用户下次拉取列表时,服务端过滤掉status=REVOKED的记录,保持体验一致










