📚 课程目录第4章消息可靠性与不丢失机制

第4章消息可靠性与不丢失机制

消息丢失是分布式系统最隐蔽的故障，大厂面试重点考察生产者、消费者、存储三个环节的可靠性设计及ACK机制的细节。本章拆解高频问题，形成可迁移的回答框架。

📌 面试问题：如何保证生产者发送的消息不丢失？

面试官考察点	是否理解生产者端可靠性链路：ACK等级、重试策略、幂等性、事务消息的适用边界。
回答框架	① 选型ACK：Kafka acks=all / RocketMQ SYNC_MASTER；② 开启重试+幂等；③ 同步发送且对回调做失败处理；④ 极端场景使用事务消息。
简短示例回答	我通常将Kafka生产端 acks=all 并启用幂等，同步发送配合回调弥补失败。对于最终一致性场景，使用RocketMQ事务消息确保本地事务与发消息原子性，日均处理2亿条零丢失。
可能追问	事务消息与普通消息的性能差异？如何处理超时未确认的事务消息？
避坑提醒	❌ 不要只依赖重试，需明确最大重试次数+死信；❌ 不要将事务消息用于高频小消息。

📌 面试问题：消息队列存储可靠性如何设计？

面试官考察点	是否掌握刷盘机制、多副本一致性、磁盘故障恢复、数据完整性校验。
回答框架	① 刷盘策略：同步刷盘 vs 异步刷盘（根据可靠性/性能权衡）；② 副本复制：ISR机制/Leader-Follower模型；③ 定期数据校验+故障自动恢复。
简短示例回答	我主导的项目采用RocketMQ同步刷盘+主从复制，每条消息等待刷盘和副本确认后返回成功。日均读写500GB，经过压测保证节点级故障零消息丢失。
可能追问	同步刷盘对TPS的影响？如何看待RAID vs 分布式副本？
避坑提醒	❌ 不要认为异步刷盘一定会丢消息——可通过多副本补偿；❌ 不要忽视操作系统页缓存刷盘时机。

📌 面试问题：消费者如何保证消息不丢失？ACK机制怎么设置？

面试官考察点	是否理解消费者消费位移提交机制、手动ACK最佳实践、幂等去重、重试与死信处理。
回答框架	① 使用手动ACK，消费成功后再提交偏移量；② 消费过程支持幂等（DB唯一键/Bitmap去重）；③ 消费失败进入重试队列+死信队列；④ 监控报警。
简短示例回答	我在实时风控系统让RocketMQ消费者手动ACK，消费数据写入DB并校验唯一键。最多重试3次，失败转入死信并告警。单日1.5亿条消息最终一致零丢失。
可能追问	如果手动ACK提交超时怎么办？如何设计重试退避策略？
避坑提醒	❌ 自动ACK + 业务处理异常 → 消息丢失；❌ 切忌无限重试导致消息堆压 → 合理最大重试+死信。

📁 项目案例：金融交易平台消息可靠传输架构

业务背景	核心交易链路需保证订单、支付、风控消息不丢失，任何丢失均造成资损。
规模指标	日消息量1.8亿+，峰值TPS 4.2万，集群节点30台；消息大小0.2KB~100KB。
技术栈	RocketMQ 5.x（事务消息 + 同步刷盘 + 主从自动切换）+ Kafka MirrorMaker（灾备）+ 自定义死信补偿服务。
核心难点	① 订单中心与消息队列之间分布式事务一致性；② 单节点故障可能丢刷盘数据；③ 消费端偶发DB连接池抖动导致ACK失败。
面试高频追问	1. 事务消息回查怎么实现？ 2. 同步刷盘下如何保证性能？ 3. 死信补偿服务如何避免重复处理？
可迁移回答话术	“我主导将RocketMQ事务消息与业务本地事务绑定，回查机制保证最终一致；存储上同步刷盘+3副本避免单点，消费端手动ACK配合DB唯一键幂等，整体达到金融级可靠。”

💡 高频加分点：主动提及“生产端+存储+消费端”完整链路设计，并给出可量化的可靠性指标（如丢消息率 < 10⁻⁶）。

⚠️ 常见失分点：只谈理论不谈实践；未区分同步刷盘与异步刷盘的性能差异；不明确ACK机制与消费重试的关系。