[SpringBoot2] Redis使用消息队列实现邮件通知的流程说明

使用Redis实现邮件通知的流程说明

1. 概述

本系统使用Redis作为消息队列实现异步邮件通知功能，采用生产者-消费者模式，确保邮件发送不阻塞主业务流程，提高系统响应速度和用户体验。系统实现了完整的消息处理机制，包括重试机制和死信队列处理。

2. 系统架构

系统主要由以下几个组件构成：

1. ApprovalNotifyProducer: 消息生产者，负责创建并发送审批通知消息到Redis队列
2. RedisQueueService: Redis队列服务，封装了Redis队列操作
3. RedisMessageQueueListener: Redis消息队列监听器，负责监听队列并分发消息
4. EmailNotifyConsumer: 邮件通知消费者，负责处理消息并发送邮件
5. FailedNotifyRetryJob: 失败通知重试定时任务，处理失败的消息
6. Dead Letter Queue (DLQ): 死信队列，存储无法处理的消息供人工干预

3. 实现流程

3.1 消息生产流程

1. 当系统需要发送审批通知时（如审批通过、退回等），业务代码调用ApprovalNotifyProducer.sendApprovalPassedNotify()方法
2. 生产者创建ApprovalNotifyMessage消息对象，包含业务单号、业务模块、审批状态、用户信息等
3. 通过RedisQueueService.pushApprovalNotify()方法将消息推送到Redis主队列中

3.2 消息消费流程

1. RedisMessageQueueListener启动后会持续监听Redis主队列
2. 当队列中有消息时，监听器获取消息并交给EmailNotifyConsumer处理
3. EmailNotifyConsumer解析消息内容，构建邮件主题和内容
4. 使用Hutool的MailUtil工具发送邮件给用户

3.3 异常处理和重试机制

1. 如果邮件发送失败，系统会捕获异常
2. 检查消息的重试次数是否达到上限（默认3次）
3. 如果未达上限，将消息放入失败队列等待重试
4. FailedNotifyRetryJob定时任务（每5分钟）会将失败队列中的消息重新放回主队列
5. 如果重试次数达到上限，消息将被放入死信队列(DLQ)等待人工处理

4. 核心组件详解

4.1 ApprovalNotifyMessage 消息实体类

包含以下关键信息：

• 消息唯一ID
• 业务单号
• 业务模块
• 审批状态
• 业务数据
• 用户ID、邮箱、姓名
• 重试次数等

4.2 Redis队列配置

系统定义了三个队列：

• oa:approval:notify:queue: 审批通知主队列
• oa:approval:notify:failed: 失败通知队列（用于重试）
• oa:approval:notify:dlq: 死信队列（Dead Letter Queue）

4.3 邮件发送配置

系统使用Hutool的MailUtil工具发送邮件，相关配置包括：

• 邮件配置见 keepc-admin/src/main/resources/config/mail.setting
• app.email.sender-name: 邮件发送者名称
• app.email.max-retry-count: 最大重试次数（默认3次）

5. 死信队列机制

5.1 死信队列的作用

死信队列用于存储无法正常处理的消息，防止这些消息无限次重试影响系统性能。当消息达到最大重试次数后，会被放入死信队列等待人工处理。

5.2 死信处理流程

1. 消息在主队列中处理失败
2. 消息被放入失败队列等待重试
3. FailedNotifyRetryJob定时任务将失败消息重新放回主队列
4. 消息重试次数达到上限（默认3次）
5. 消息被放入死信队列
6. 系统管理员定期检查死信队列，进行人工干预

5.3 死信队列配置

app:
  redis:
    queues:
      approval-notify: oa:approval:notify:queue  # 审批通知主队列
      failed-notify: oa:approval:notify:failed   # 失败通知队列
      dlq-notify: oa:approval:notify:dlq         # 死信队列

6. 系统优势

1. 异步处理: 邮件发送不阻塞主业务流程，提高系统响应速度
2. 可靠性: 通过失败重试机制和死信队列确保消息最终能够被正确处理
3. 解耦: 生产者和消费者分离，便于维护和扩展
4. 可监控: 详细的日志记录，便于问题排查
5. 容错性: 通过死信队列防止无法处理的消息影响系统稳定性

7. 工作流程图

业务系统
    ↓ (触发通知)
ApprovalNotifyProducer
    ↓ (放入主队列)
Redis主队列(oa:approval:notify:queue)
    ↓ (监听获取)
RedisMessageQueueListener
    ↓ (处理消息)
EmailNotifyConsumer → 发送邮件
    ↓ (失败?)
    ├── 是 → 重试次数<N → 放入失败队列 → FailedNotifyRetryJob定时重试
    └── 重试次数>=N → 放入死信队列(oa:approval:notify:dlq)

8. 关键配置

8.1 Redis队列配置

app:
  redis:
    queues:
      approval-notify: oa:approval:notify:queue  # 审批通知主队列
      failed-notify: oa:approval:notify:failed   # 失败通知队列
      dlq-notify: oa:approval:notify:dlq         # 死信队列

8.2 邮件通知配置

app:
  email:
    sender-name: OA系统通知      # 邮件发送者名称
    max-retry-count: 3          # 最大重试次数

9. 总结

该基于Redis的邮件通知系统实现了高可用、异步和可靠的消息处理机制，通过主队列、失败队列和死信队列三级处理机制，确保了重要业务通知能够及时准确地发送给用户。当消息无法处理时，通过死信队列进行隔离，避免影响整个系统的稳定性，同时为系统管理员提供了人工干预的途径。

10. 代码实现

代码