Kafka是大型架构的必备中间件，下面我详解Kafka 消息不丢失方案@mikechen
Kafka生产端
消息最容易在发送到 Broker 的网络过程中丢失，生产者需要严格配置以确保消息被 Broker 确认接收。
生产者可以配置 acks 策略（例如 acks=all），要求 leader 等待所有同步副本确认后才返回成功。
从而确保消息在多个副本上被持久保存，增强耐久性。
使用带回调的异步发送、和开启重试(retries)，来避免网络抖动导致消息丢失。
配置 retries + max.in.flight.requests.per.connection=1，防止顺序错乱。
开启幂等性
启用 idempotence=true（幂等生产者），避免重复消息。
开启幂等性后，Kafka 为每个生产者和分区分配唯一标识符和序列号，Broker 端会根据这些信息对重复发送的消息进行去重处理。
确保开启重试（retries）机制时，即使重试，消息也不会重复写入。
从而实现恰好一次（Exactly Once）语义，安全地保证了消息不丢失。
副本机制配置
Kafka 将每个分区的数据在集群中的多个 Broker 上以副本形式保存。
每个分区有一个领导者（leader）和若干跟随者（follower）。
生产者写入由 leader 负责，followers 异步或同步地复制数据。通过配置副本因子（replication.factor）和最小同步副本数（min.insync.replicas）。
Kafka 能在 broker 宕机或网络分区时仍保留数据副本，从而避免单点故障导致的消息永久丢失。
比如：
开启 replication.factor >= 3，保证多副本冗余。
设置 min.insync.replicas=2，确保至少两个副本写入成功。
Broker持久化和刷盘优化
Kafka 的高吞吐依赖于 顺序写磁盘 + Page Cache，但如果 Broker 异常宕机。
尚未刷盘的数据可能丢失，因此需要合理优化 刷盘策略 来提升可靠性。
默认情况下 Kafka 依赖操作系统 Page Cache，刷盘频率较低。
调小刷盘间隔，可以让消息更快落到磁盘，降低宕机丢失风险。
比如：可通过 log.flush.scheduler.interval.ms 调整周期性刷盘调度频率。
但是，这里需要注意：刷盘过于频繁会降低吞吐，需要在 性能与可靠性 之间平衡。