场景题：线上消息队列故障，兜底改造方案

线上消息队列故障可能会导致系统无法正常处理消息，进而影响业务逻辑。为了应对这种情况，需要设计一个兜底改造方案，确保在消息队列故障时系统仍能正常运行或快速恢复。以下是一个详细的兜底改造方案：

---

1. 消息队列故障的影响

• 生产者无法发送消息：业务数据无法进入消息队列，可能导致数据丢失或业务中断。
• 消费者无法消费消息：业务逻辑无法执行，可能导致任务积压或业务延迟。
• 消息丢失或重复：消息队列故障可能导致消息丢失或重复消费。

---

2. 兜底改造方案设计

2.1 生产者兜底方案

• 本地消息表：
  • 在业务数据库中创建一张本地消息表，用于存储待发送的消息。
  • 生产者先将消息写入本地消息表，再尝试发送到消息队列。
  • 如果消息队列发送失败，可以通过定时任务重试发送。
  • 示例表结构：

    CREATE TABLE local_message (
        id BIGINT PRIMARY KEY AUTO_INCREMENT,
        topic VARCHAR(255) NOT NULL,
        content TEXT NOT NULL,
        status TINYINT NOT NULL DEFAULT 0, -- 0: 未发送, 1: 已发送
        created_at DATETIME NOT NULL,
        updated_at DATETIME NOT NULL
    );

• 异步重试机制：
  • 使用异步任务（如定时任务或线程池）定期扫描本地消息表，重新发送未成功的消息。
  • 设置最大重试次数，避免无限重试。
• 降级策略：
  • 如果消息队列完全不可用，可以降级为直接调用业务逻辑，避免业务中断。
  • 示例：

    try {
        // 尝试发送消息
        messageQueue.send(message);
    } catch (Exception e) {
        // 降级为直接处理
        handleMessageDirectly(message);
    }

2.2 消费者兜底方案

• 消息消费幂等性：
  • 确保消费者的业务逻辑是幂等的，即使消息重复消费也不会产生副作用。
  • 示例：使用唯一键或状态字段避免重复处理。
• 本地消费记录：
  • 在消费者端维护一张本地消费记录表，记录已处理的消息 ID。
  • 在处理消息前，先检查该消息是否已处理过。
  • 示例表结构：

    CREATE TABLE consumed_message (
        id BIGINT PRIMARY KEY,
        consumed_at DATETIME NOT NULL
    );

• 死信队列：
  • 配置死信队列（DLQ），将处理失败的消息转移到死信队列。
  • 后续可以通过人工或自动任务处理死信队列中的消息。
• 降级策略：
  • 如果消息队列不可用，消费者可以降级为从本地消息表或数据库中拉取消息进行处理。

2.3 消息队列高可用改造

• 集群部署：
  • 使用消息队列的集群模式（如 Kafka 集群、RocketMQ 集群）提高可用性。
• 多活架构：
  • 在多机房或多地域部署消息队列，实现异地多活。
• 监控与报警：
  • 部署消息队列的监控系统（如 Prometheus + Grafana），实时监控消息队列的健康状态。
  • 设置报警规则，及时发现和处理故障。

2.4 数据一致性保障

• 分布式事务：
  • 对于强一致性要求的场景，可以使用分布式事务（如 Seata）确保消息发送和业务操作的一致性。
• 最终一致性：
  • 对于弱一致性场景，可以通过本地消息表和异步重试机制实现最终一致性。

---

3. 故障恢复流程

1. 故障检测：
   • 通过监控系统发现消息队列故障。
2. 切换兜底方案：
   • 生产者切换到本地消息表，消费者切换到本地消费记录或降级逻辑。
3. 故障修复：
   • 运维团队修复消息队列故障。
4. 数据同步：
   • 将本地消息表中的未发送消息重新发送到消息队列。
   • 将本地消费记录与消息队列中的消息进行比对，确保无遗漏或重复。
5. 恢复生产：
   • 恢复消息队列的正常使用，关闭兜底逻辑。

---

4. 总结

• 生产者兜底：使用本地消息表和异步重试机制，确保消息不丢失。
• 消费者兜底：保证消费幂等性，使用本地消费记录和死信队列。
• 高可用改造：通过集群部署和多活架构提高消息队列的可用性。
• 故障恢复：制定清晰的故障恢复流程，确保系统快速恢复。

通过以上兜底改造方案，可以在消息队列故障时最大限度地保障系统的可用性和数据的一致性。