在线教育消息通知系统技术方案：模板治理、多渠道投递、调度防重与可靠触达

消息通知系统是在线教育平台中非常容易被低估的基础模块。它不直接承载课程学习、考试判分或证书生成，却决定了用户是否能及时知道课程上线、考试开始、作业截止、证书发放和系统公告。通知系统一旦缺少可靠设计，就会出现消息漏发、重复提醒、渠道发送失败不可追踪、批量推送拖慢主流程、第三方限流导致大面积失败等问题。

织码在线教育系统的通知模块围绕“业务事件标准化、通知模板可治理、投递任务可追踪、渠道发送可隔离、失败结果可补偿”几个原则设计。系统支持站内信、邮件、微信模板消息三类渠道，既能处理即时通知，也能处理考试前提醒、培训任务截止提醒这类定时通知。

1. 从业务事件到通知任务：先拆清系统边界

通知系统不应该只是一个工具类。真正可维护的通知中心，至少要拆成五层：事件接入层、模板渲染层、任务调度层、渠道投递层和状态观测层。

这种分层的核心收益是解耦。课程系统只需要提交“课程已上线”事件，不需要知道用户是否绑定微信、邮件是否可达、模板 ID 是否存在、第三方接口是否限流。

2. 模板治理：不仅是字符串替换，还要可校验、可版本化

原文中的 notify_template 表已经覆盖了模板编码、名称、通知类型、渠道、标题模板、内容模板和微信模板 ID。技术增强版建议增加变量定义、模板版本和审核状态，便于运营和技术共同维护。

CREATE TABLE `notify_template` (
  `id` bigint NOT NULL COMMENT '模板ID',
  `code` varchar(50) NOT NULL COMMENT '模板编码，业务唯一',
  `name` varchar(100) NOT NULL COMMENT '模板名称',
  `notify_type` tinyint NOT NULL COMMENT '1课程 2考试 3证书 4培训任务 5系统',
  `channels` varchar(100) NOT NULL COMMENT '发送渠道: inApp,email,wechat',
  `title_template` varchar(200) NOT NULL COMMENT '标题模板',
  `content_template` text NOT NULL COMMENT '正文模板',
  `variables_schema` json DEFAULT NULL COMMENT '变量定义和必填项',
  `wechat_template_id` varchar(80) DEFAULT NULL COMMENT '微信模板ID',
  `version` int NOT NULL DEFAULT 1 COMMENT '模板版本',
  `status` tinyint NOT NULL DEFAULT 0 COMMENT '0启用 1禁用 2草稿',
  `create_time` datetime NOT NULL,
  `update_time` datetime DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_code_version` (`code`, `version`)
+) ENGINE=InnoDB COMMENT='通知模板表';

模板渲染不能只做 String.replace，至少要补齐三个校验：必填变量是否完整、渲染后是否还有未解析占位符、不同渠道是否满足长度和格式限制。

public RenderedMessage renderMessage(String templateCode, Map<String, Object> variables) {
    NotifyTemplate template = templateMapper.selectActiveByCode(templateCode);
    if (template == null) {
        throw new BizException("通知模板不存在或未启用: " + templateCode);
    }
    variableValidator.validate(template.getVariablesSchema(), variables);
    String title = templateEngine.render(template.getTitleTemplate(), variables);
    String content = templateEngine.render(template.getContentTemplate(), variables);
    placeholderValidator.ensureResolved(title, content);
    channelLimitValidator.validate(template.getChannels(), title, content);
    return RenderedMessage.builder()
        .templateCode(template.getCode())
        .templateVersion(template.getVersion())
        .channels(ChannelParser.parse(template.getChannels()))
        .title(title)
        .content(content)
        .wechatTemplateId(template.getWechatTemplateId())
        .build();
}

3. 投递任务模型：先落库，再异步发送

原文使用 @Async 线程池实现异步发送，适合轻量场景。更可靠的做法是先创建通知任务，再由消费者异步投递。这样即使服务重启、线程池拒绝、第三方接口失败，也能根据任务状态继续补偿。

CREATE TABLE `notify_task` (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `template_code` varchar(50) NOT NULL,
  `template_version` int NOT NULL DEFAULT 1,
  `user_id` bigint NOT NULL,
  `biz_type` varchar(50) DEFAULT NULL,
  `biz_id` bigint DEFAULT NULL,
  `channels` varchar(100) NOT NULL,
  `variables` json NOT NULL,
  `title` varchar(200) DEFAULT NULL,
  `content` text,
  `status` tinyint NOT NULL DEFAULT 0 COMMENT '0待发送 1发送中 2成功 3部分成功 4失败 5跳过',
  `retry_count` int NOT NULL DEFAULT 0,
  `next_retry_time` datetime DEFAULT NULL,
  `idempotent_key` varchar(128) NOT NULL,
  `plan_send_time` datetime DEFAULT NULL,
  `create_time` datetime NOT NULL,
  `update_time` datetime DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_idempotent_key` (`idempotent_key`),
  KEY `idx_status_retry` (`status`, `next_retry_time`),
  KEY `idx_plan_send_time` (`plan_send_time`)
+) ENGINE=InnoDB COMMENT='通知发送任务表';

幂等键可以由业务类型、业务 ID、模板编码、用户 ID 和触发时机组成，例如 exam:10086:EXAM_REMINDER:user:9527:T-60m。这能防止定时任务多次扫描、接口重复调用或业务事件重复投递导致同一个用户收到多条相同提醒。

4. 多渠道适配器：统一协议，独立记录结果

站内信、邮件、微信模板消息的发送模型不同。统一接口可以简化业务层，但系统内部仍应保留每个渠道的投递结果。

public interface MessageChannel {
    String getChannelName();
    ChannelSendResult send(ChannelMessage message);
}

每个渠道都应返回标准结果：成功、失败、跳过、是否可重试、失败原因和第三方请求 ID。

public ChannelSendResult sendByChannel(String channelName, ChannelMessage message) {
    MessageChannel channel = channelMap.get(channelName);
    if (channel == null) {
        return ChannelSendResult.failed(channelName, false, "渠道不存在");
    }
    try {
        return channel.send(message);
    } catch (RateLimitException e) {
        return ChannelSendResult.failed(channelName, true, "渠道限流");
    } catch (InvalidReceiverException e) {
        return ChannelSendResult.skipped(channelName, "接收人信息缺失");
    } catch (Exception e) {
        return ChannelSendResult.failed(channelName, true, e.getMessage());
    }
}

建议增加渠道发送明细表，记录 task_id、channel、receiver、status、retryable、error_msg、provider_msg_id 和 send_time。这样才能解释“站内信收到了，但微信没收到”“邮件因为地址为空被跳过”“微信接口限流后进入重试”等问题。

5. 异步执行：线程池只是执行器，不是可靠队列

@Async 的价值是让业务主流程不等待通知发送，但它不是可靠消息队列。线程池队列满、应用重启、任务执行中异常，都可能导致消息丢失。因此建议使用“任务表 + 扫描器 + 线程池”的组合。

@Scheduled(fixedDelay = 3000)
public void dispatchPendingTasks() {
    List<NotifyTask> tasks = taskMapper.lockPending(100, new Date());
    for (NotifyTask task : tasks) {
        messageThreadPool.execute(() -> taskSender.send(task));
    }
}

任务发送器负责渲染模板、按渠道发送、汇总渠道结果并更新任务状态。线程池配置仍然重要。核心线程数、最大线程数、队列容量和拒绝策略需要结合渠道吞吐能力配置。邮件和微信接口通常有频率限制，不能只靠增加线程数提升速度。

6. 定时通知：扫描窗口、防重和多节点调度

考试前 1 小时提醒、培训任务截止前 1 天提醒，都属于计划型通知。原文使用定时任务扫描并通过 Redis 防重，这是一个实用起点。技术增强版建议进一步把计划发送时间写入 notify_task.plan_send_time，让调度变成“生成任务”和“执行任务”两个阶段。

@Scheduled(fixedRate = 5 * 60 * 1000)
public void scanExamReminders() {
    Date from = DateUtil.offsetHour(new Date(), 1);
    Date to = DateUtil.offsetMinute(from, 5);
    List<Exam> exams = examMapper.selectStartingBetween(from, to);
    for (Exam exam : exams) {
        for (Long userId : examRegistrationMapper.selectUserIds(exam.getId())) {
            String idempotentKey = IdempotentKey.examReminder(exam.getId(), userId, "T-60m");
            notifyTaskService.createIfAbsent(idempotentKey, NotifyTaskCreateCommand.builder()
                .templateCode("EXAM_REMINDER")
                .userId(userId)
                .bizType("exam")
                .bizId(exam.getId())
                .planSendTime(new Date())
                .variables(buildExamVariables(exam))
                .build());
        }
    }
}

多节点部署时，扫描任务需要分布式锁或分片机制。即使用了分布式锁，也不能只靠锁保证不重复，数据库唯一索引仍然是最后防线。

7. 站内信与未读数：稳定兜底渠道要设计好读写模型

站内信是通知系统的兜底渠道。用户没有邮箱、没有绑定微信时，站内信仍然能在登录后触达。原文的 notify_message 表可以继续使用，并通过 idx_user_read 支撑未读列表和未读数查询。

未读数可以缓存，但缓存失效策略要清晰：写入站内信后删除未读数缓存，标记已读后删除未读数缓存，读取时缓存短时间结果。

public int getUnreadCount(Long userId) {
    String key = "notify:unread:" + userId;
    String cached = redisTemplate.opsForValue().get(key);
    if (cached != null) {
        return Integer.parseInt(cached);
    }
    int count = messageMapper.countUnread(userId);
    redisTemplate.opsForValue().set(key, String.valueOf(count), 5, TimeUnit.MINUTES);
    return count;
}

前端 30 秒轮询适合大多数企业培训和教培场景。如果通知实时性要求更高，可以在站内信写入后通过 WebSocket 或 SSE 推送未读数变化，但这应作为增强能力，而不是通知系统可靠性的前提。

8. 失败分类、重试策略和限流控制

重试时间可以采用简单退避策略：

public Date nextRetryTime(int retryCount) {
    int[] delays = {1, 5, 15, 60};
    int index = Math.min(retryCount, delays.length - 1);
    return DateUtil.offsetMinute(new Date(), delays[index]);
}

批量推送时还要考虑渠道限流。邮件和微信都不适合无限并发，建议按渠道配置令牌桶或固定速率队列。站内信写库能力较强，但也要分批插入，避免一次性写入过大事务。

9. 可观测性：通知系统必须能回答“为什么没收到”

通知系统的排障入口通常来自用户反馈：“我没收到考试提醒”。因此系统需要围绕用户、业务、模板和渠道建立可查询链路。

监控指标建议覆盖：任务创建量、渠道发送成功率、渠道失败率、平均耗时、重试队列长度、死信任务数量、模板渲染失败数量、调度扫描耗时。告警不应只看总失败数，还要按渠道和模板区分，否则很难定位是微信配置错误、邮件服务故障，还是某个业务模板变量缺失。

10. 在线教育场景下的通知策略建议

不同通知场景不应该使用同一套渠道策略。

渠道不是越多越好。对低优先级运营通知，应控制频率和退订策略；对考试提醒、任务截止等强业务通知，则应更重视送达率和失败补偿。

总结

织码在线教育系统的消息通知模块，不只是把站内信、邮件和微信模板消息封装到一起，而是围绕可靠触达建立了一套完整链路：模板治理保证内容可控，通知任务表保证投递可追踪，幂等键避免重复提醒，多渠道适配器隔离渠道差异，定时调度覆盖考试和任务提醒，失败分类与重试策略降低漏发风险，可观测性能力帮助技术和运营解释每一条通知的发送结果。

对于企业培训、教培机构、在线考试和知识付费平台来说，通知系统的价值不仅在“发出去”，更在于让关键学习节点能够被及时、准确、可追踪地触达。这样的通知模块更适合长期运营，也更容易支撑私有化部署、组织级培训和多业务线扩展。

如需了解织码在线教育系统的私有化部署、通知模块演示或企业培训数字化方案，可访问官网 https://www.weavecodes.com/。
递可追踪，幂等键避免重复提醒，多渠道适配器隔离渠道差异，定时调度覆盖考试和任务提醒，失败分类与重试策略降低漏发风险，可观测性能力帮助技术和运营解释每一条通知的发送结果。

对于企业培训、教培机构、在线考试和知识付费平台来说，通知系统的价值不仅在“发出去”，更在于让关键学习节点能够被及时、准确、可追踪地触达。这样的通知模块更适合长期运营，也更容易支撑私有化部署、组织级培训和多业务线扩展。

如需了解织码在线教育系统的私有化部署、通知模块演示或企业培训数字化方案，可访问官网 https://www.weavecodes.com/。