面对线上消息队列出现故障的场景，如何设计一套兜底改造方案来保障系统的可靠性和数据不丢失？

回答思路

1. 【回答框架 1】消息队列故障的核心风险是消息积压、丢失或消费中断，兜底方案需围绕可用性、数据一致性和最终一致性展开。先明确故障类型：是MQ服务不可用、网络分区、还是消费端处理异常，不同故障对应不同策略。
2. 【回答框架 2】本地消息表方案：生产者将消息和业务操作写入同一个本地事务，通过定时任务扫描未发送的消息并重投递到MQ，配合消费端幂等处理保证不重复消费。
3. 【回答框架 3】消息降级方案：当MQ不可达时，将消息暂存至数据库、Redis或本地文件，待MQ恢复后再异步补偿推送，同时限制队列长度和降级阈值，避免堆积。
4. 【回答框架 4】消费端兜底：消费逻辑需支持重试与死信队列，对失败消息进行延迟重试或转入人工处理；同时增加消息幂等性设计（如唯一键）防止重复处理带来的数据错乱。
5. 【回答框架 5】监控与恢复：建立MQ集群监控、消费延迟、积压量告警，故障时自动切换备用通道或触发补偿任务，并通过演练验证兜底链路有效性。
6. 【关键点 1】核心是保证消息不丢失，可结合本地事务和消息表实现可靠投递。
7. 【关键点 2】降级策略需明确触发条件，避免长时间降级造成存储压力。
8. 【关键点 3】消费端必须设计幂等，防止重复消息引发业务异常。
9. 【关键点 4】故障恢复后要有补偿机制，确保积压消息最终处理完成。
10. 【易错点 1】勿忽略消费端重试风暴，需限制重试次数并退避。
11. 【易错点 2】不要把兜底方案当作长期替代，MQ恢复后应及时切回并清理临时存储。
12. 【易错点 3】防止本地消息表与业务操作不一致，需用同一事务或补偿事务保证原子性。