Kafka是大型架构核心，下面我详解Kafka消息不丢失方案@mikechen
生产端：防止消息发送丢失
生产端层面，通过合理的确认级别和重试策略，最大程度保证消息在发送阶段不丢失或被无意吞掉。
acks（确认级别）：推荐设置为 all（或 -1），只有所有 ISR 副本都确认后才算提交。
这能最大程度避免因单点副本故障导致的消息丢失，但会牺牲一定的吞吐量与时延。
重试与退避：配置合理的 retries 值。
并结合指数退避策略，处理网络抖动或短时 Broker 故障导致的发送失败。
必要时增加 max.in.flight.requests.per_connection 的限制，避免重试导致消息乱序。
Broker端：防止消息存储丢失
Broker（集群）层面：通过适当的副本、同步性设置与领导者选举策略。
确保消息在多个副本之间持久化，降低单点故障导致的丢失概率。
建议设置为一个合理的副本数（通常>=3），以容错至少一个副本不可用时仍能保持服务可用与数据不丢失。
min.insync.replicas：设为大于1，通常设置为 2 或 3。
确保在缺少足够的 ISR 时不会将数据标记为已提交，增加持久性保障。
确保磁盘持久性、写入延迟、网络带宽与丢包率在可控范围，关键路径上的磁盘应开启对齐、开启顺序写入优化等。
消费端：防止消息消费丢失
消费端层面：确保偏移量提交在“消费完成后”再标记消费。
必要时引入幂等消费和幂等性处理，避免重复消费或漏消费。
使用手动提交（或分布式事务/Exactly-Once 方案），确保只有在消息己成功被业务处理后才提交偏移量，避免漏消费或重复消费。
消费端实现幂等性（如幂等写入、去重表、幂等键等），并对失败场景实施幂等失败回滚策略。
必要时，将失败消息写入死信队列，以防止丢失。
