Kafka消息丢失Linux环境解决方案
调整acks参数，强制所有副本确认
将生产者的acks参数设置为all（或-1），要求Leader副本及所有同步副本（ISR）都成功接收消息后才返回发送成功响应。这是防止生产者端消息丢失的核心配置，即使Leader宕机，也能确保消息已同步至其他副本。
启用重试机制，应对临时故障
配置retries参数为较大值（如Integer.MAX_VALUE），并设置合理的retry.backoff.ms（如1000ms），当发送过程中出现网络抖动、Leader切换等临时异常时，生产者会自动重试发送，避免消息因偶发故障丢失。
使用带回调的异步发送，处理失败消息
避免使用producer.send(msg)的同步发送方式（会阻塞生产者线程），改用producer.send(msg, callback)的异步方式。通过回调函数检查发送结果（如onCompletion方法），若发送失败（如NotEnoughReplicasException），可将消息记录到本地数据库或消息队列，后续通过定时任务重新发送。
设置min.insync.replicas，拒绝未同步写入
在Broker端配置min.insync.replicas≥2（需大于1），要求消息至少被写入指定数量的同步副本才算成功。若同步副本数量不足，生产者会收到NotEnoughReplicasException异常，从而停止发送，避免消息写入未同步的副本。
增加副本因子，提升数据冗余
将Topic的replication.factor设置为≥3（生产环境建议奇数，如3或5），确保每个分区有多个副本分布在不同Broker上。当Leader副本宕机时，ZooKeeper会从ISR中选举新的Leader，避免单点故障导致的数据丢失。
禁止非ISR副本参与Leader选举
设置unclean.leader.election.enable=false（默认值），禁止非同步副本（不在ISR列表中的副本）参与Leader选举。若允许非ISR副本成为Leader，可能导致未同步的消息丢失（如副本落后太多，无法提供完整数据）。
优化刷盘策略，减少宕机丢失
Kafka默认采用异步刷盘（log.flush.interval.messages和log.flush.interval.ms为默认值），虽提升了性能，但宕机时可能丢失未刷盘的Page Cache数据。可根据业务需求调整刷盘频率（如log.flush.interval.ms=1000，每1秒刷盘一次），或在server.properties中添加log.flush.scheduler.interval.ms=500（每500毫秒调度一次刷盘），平衡性能与可靠性。
监控Broker状态，及时处理故障
使用Kafka自带的命令（如kafka-broker-api-versions.sh、kafka-topics.sh --describe）或第三方监控工具（如Prometheus+Grafana），实时监控Broker的CPU、内存、磁盘空间、网络流量及副本同步状态。当发现磁盘空间不足（如超过80%）或副本同步滞后（如ISR列表缩小），及时清理过期日志（kafka-delete-records.sh）或扩容Broker。
关闭自动提交，手动管理Offset
将消费者的enable.auto.commit设置为false，避免自动提交Offset（默认每5秒提交一次）导致的问题：若消费者处理消息后但在提交Offset前宕机，消息会丢失。改为手动提交（consumer.commitSync()或consumer.commitAsync()），在消息处理完成后（如业务逻辑执行成功）再提交Offset，确保消息不丢失。
实现幂等性处理，避免重复消费
即使手动提交Offset，仍可能因消费者重启、Broker重试等原因导致消息重复消费。需在消费者业务逻辑中实现幂等性（如使用唯一ID去重、数据库唯一约束），确保重复处理的消息不会影响业务结果。
处理消费滞后，避免Rebalance丢失
调整消费者的max.poll.interval.ms（如300000ms，5分钟）和session.timeout.ms（如10000ms，10秒），避免因消费速度慢（如处理一条消息耗时过长）导致的心跳超时，触发Rebalance（消费者组重新分配分区）。Rebalance时，未提交Offset的消费者会失去分区所有权，导致消息丢失。同时，可通过增加消费者实例（横向扩展）提高消费速度。
使用死信队列，处理失败消息
对于处理失败的消息（如业务逻辑异常、网络超时），不要直接丢弃，而是将其发送到专门的死信队列（Dead Letter Queue, DLQ）。后续可通过人工介入或自动化脚本分析失败原因（如数据格式错误、依赖服务不可用），并进行重试或修复，避免消息永久丢失。
使用SSD存储，提高I/O性能
Kafka的高吞吐量依赖磁盘I/O性能，建议将Broker的log.dirs（日志目录）配置在SSD上（而非HDD），减少消息写入和读取的延迟。同时，确保SSD有足够的剩余空间（建议预留20%以上），避免磁盘写满导致Broker宕机。
调整系统参数，优化网络与内存
ulimit -n（如设置为65535），避免因文件描述符不足导致连接被拒绝。net.core.somaxconn（如设置为1024）、net.ipv4.tcp_tw_reuse（如设置为1）等参数，提高网络连接的并发处理能力和复用率，减少网络延迟。-Xmx）设置为物理内存的1/4-1/2，剩余内存留给Page Cache，提升消息的缓存命中率。部署监控系统，实时预警
使用Prometheus采集Kafka的指标（如kafka_server_brokertopicmetrics_messages_in_total、kafka_controller_offline_replicas_total），并通过Grafana展示监控大盘。设置告警规则（如消息入站速率下降超过50%、ISR副本数少于2），当出现异常时及时通知运维人员处理，避免问题扩大。
