在Java中如何构建系统公告推送_公告推送结构解析

Java公告推送系统含5大模块：公告实体、发布中心、分发引擎、多端适配器、阅读跟踪；需保障幂等性、动态人群计算、离线兜底及内容审核，并支持分级推送。

Java中构建系统公告推送，核心在于解耦通知逻辑与业务逻辑，同时保证实时性、可扩展性和可靠性。公告推送结构不是简单发个消息，而是包含发布、存储、分发、接收、回执等完整链路。

公告推送的核心结构组成

一个健壮的公告推送系统通常包含以下5个关键模块：

• 公告实体（Notice）：定义标题、内容、优先级、生效时间、过期时间、目标人群（角色/用户ID/部门）、是否置顶、阅读状态等字段；建议用JPA或MyBatis映射持久化。
• 发布中心（NoticePublisher）：负责校验权限、组装公告、写入数据库，并触发分发动作；支持同步发布（立即推）和异步发布（定时任务触发）。
• 分发引擎（NoticeDispatcher）：根据目标规则（如全员、某角色、指定用户列表）生成推送任务；推荐结合消息队列（如RabbitMQ/Kafka）解耦，避免阻塞主流程。
• 多端适配器（NoticeAdapter）：统一接口，向下对接不同渠道——WebSocket（在线用户实时弹窗）、站内信（存库+未读数统计）、邮件、短信、企业微信/钉钉机器人等。
• 阅读跟踪（ReadReceiptService）：记录用户已读/未读/忽略状态，支持“已读回执”和“强制已读”（如重要公告超时自动标记）。

典型推送流程示例（代码骨架）

以Spring Boot为例，简化关键环节：

// 1. 发布入口（Controller）
@PostMapping("/notices/publish")
public Result publish(@RequestBody NoticeRequest req, Principal principal) {
    Notice notice = noticePublisher.publish(req, principal.getName());
    return Result.success(notice.getId());
}

// 2. 分发触发（Publisher内调用）
public Notice publish(NoticeRequest req, String operator) {
    Notice notice = Notice.builder()
        .title(req.getTitle())
        .content(req.getContent())
        .targetType(req.getTargetType()) // "ALL", "ROLE_ADMIN", "USER_IDS"
        .targetIds(req.getTargetIds())
        .publishTime(LocalDateTime.now())
        .build();
    noticeMapper.insert(notice);

    // 异步分发（@Async 或发MQ）
    notice
Dispatcher.dispatchAsync(notice);
    return notice;
}

// 3. WebSocket实时推送（适配器之一）
@Scheduled(fixedDelay = 5000) // 或监听MQ消费后触发
public void pushToOnlineUsers(Notice notice) {
    Set targetSessions = sessionManager.findSessionsByTarget(notice.getTargetType(), notice.getTargetIds());
    targetSessions.forEach(sessionId -> {
        try {
            sessionManager.getSession(sessionId).getBasicRemote().sendText(
                JSON.toJSONString(new NoticePushDTO(notice))
            );
        } catch (IOException ignored) {}
    });
}

设计时容易忽略的关键细节

实际落地中，这几个点常决定系统是否稳定可用：

• 幂等性保障：同一公告对同一用户只记录一次未读，避免重复插入read_receipt表；可用唯一联合索引（notice_id + user_id）约束。
• 目标人群动态计算：不建议在发布时就固化用户列表（易过期），而应在分发时实时查（如“当前所有在职HR”），配合缓存减少DB压力。
• 离线兜底机制：WebSocket断连用户需在重连后拉取“未读公告列表”，服务端保留最近N条（如7天）未读公告快照。
• 敏感内容脱敏与审核：生产环境建议增加NoticeAuditService，对含关键词（如“停服”“故障”）的公告走人工审核流，避免误发引发舆情。

扩展建议：分级与场景化

公告不是“一刀切”，应按业务语义分级管理：

• 系统级（红色标徽）：停机维护、安全漏洞，强制弹窗+短信+邮件三通道，阅读后需点击确认。
• 业务级（黄色标徽）：新功能上线、流程变更，站内信+WebSocket，48小时内未读自动转邮件。
• 提示级（灰色标徽）：操作引导、小贴士，仅在相关页面顶部Banner展示，不计入未读计数。

基本上就这些。结构清晰了，后续加定时推送、A/B测试推送、阅读率分析，都顺理成章。