面试必问：Kafka如何保证消息不丢失_面试题:说说你如何保证kafka不丢失消息?-CSDN博客

Kafka如何保证消息不丢失

消息的生产者端，最怕的就是消息发送给Kafka集群的过程中失败，所以，我们需要有机制来确保消息能够发送成功，但是，因为存在网络问题，所以基本没有什么办法可以保证一次消息一定能成功。

消息确认机制：生产者发送消息时可设置acks参数来决定确认级别。acks=0表示生产者不等待消息确认直接发送，可能丢消息；acks=1表示消息被 Leader 副本确认接收即视为成功，若 Leader 副本接收后故障且 Follower 副本未复制，消息可能丢失；acks=all（或acks=-1）表示所有 ISR 副本都确认接收到消息，生产者才视为发送成功，能最大程度确保消息不丢失，但会降低性能。
重试机制：通过设置retries参数，当出现网络抖动、Broker 故障等导致消息发送失败时，生产者可自动重试发送消息。
使用回调函数：使用producer.send(msg, callback)接口，根据回调处理消息提交失败情况，若是瞬时错误可重试，若是消息不合规则调整格式后重发。

Kafka的集群有一些机制来保证消息的不丢失，比如复制机制、持久化存储机制以及ISR机制。

副本机制：每个分区有一个 Leader 副本和多个 Follower 副本，Leader 副本处理消息，Follower 副本复制 Leader 副本数据。当 Leader 副本出现故障，Follower 副本可接替工作，保证消息不丢失。
ISR 机制：只有与 Leader 副本数据同步差距不大的 Follower 副本才在 ISR 中。Leader 副本会将消息发送给 ISR 中的 Follower 副本，并等待所有副本都成功接收消息后才发送ack确认消息。
刷盘策略优化：合理调整刷盘策略，如log.flush.interval.messages（多少条消息刷盘一次）、log.flush.interval.ms（隔多长时间刷盘一次）等参数，保证消息及时刷盘持久化，减少因 Broker 故障导致内存中消息丢失的风险。
配置参数优化：设置unclean.leader.election.enable = false，控制有资格竞选分区 Leader 的 Broker，避免落后太多的 Broker 成为新 Leader 导致消息丢失。同时设置replication.factor >= 3，保存多份消息冗余，并设置min.insync.replicas > 1，控制消息至少要被写入到多少个副本才算是“已提交”，提升消息持久性。

作为Kafka的消费者端，只需要确保投递过来的消息能正常消费，并且不会胡乱的提交偏移量就行了。

关闭自动提交 offset：若消费者端开启多线程异步消费，不要开启自动提交offset，由消费者端程序自己处理offset的提交更新，确保消息真正被消费后再更新offset，避免因线程运行失败但offset已更新导致消息丢失。
结合同步和异步提交：在处理循环中使用异步提交以获得更高吞吐量，在异常处理中使用同步提交以确保始终提交最后一个偏移量，这样可以在保证消息不丢失的同时，提高消费的效率。