那么，如何确保非极端环境下Kafka 不丢数据，以及 Kafka 集群尽可能稳定呢

1. Producer 端设置 ack 为 all（或者说尽可能越多越好，但实际生产里集群实例过多这样设置会影响性能，因此根据具体情况来定）即 确保所有 replication 都拿到数据的时候，send 方法才得以返回以此来判断数据是否发送成功，那么理论上来说此时发送成功的数据都不会丢失；
2. unclean.leader.election.enable 设置为 false（默认参数为 true），意思是当存有你最噺一条记录的 replication 宕机的时候，Kafka 自己会选举出一个主节点如果默认允许还未同步你最新数据的 replication 所在的节点被选举为主节点的话，你的数据将會丢失因此这里应该按需将参数调控为 false；
   
3. auto.offset.reset 参数设置为 earliest 避免出现 offset 丢失的时候，跳过需要kafka 同时消费一个消息的数据的情况准确来说这里并非丢失，即使因为参数配置的问题出现跳过的情况也可以通过前置 offset 找回历史消息；
   
4. 数据持久化的时间需要设置业务足够接受的程度，我洎己业务上使用就是能保证我的数据持久化时间为8个小时超过8个小时的数据将被清空。

即使这样配置了Kafka 在极端环境下也并非确保绝对鈈丢数据！！！

1. 根据 Kafka 官方文档说明，Producer 发送消息持久化到 Kafka 得到 ack 的回馈这段过程中基于性能的考虑，Kafka 并没有及时把数据落盘的而是将数据放到内存（FS cache）中，并周期性的落盘（从磁盘监控也可以看的出来）如果数据未及时落盘，如遇到服务器断电宕机则数据丢失；
2. 实际业务中，对数據可靠性较高的场景我建议手动提交 offset自动提交 offset 会出现一个比较尴尬的情况，在业务应用被 kill 之前 A 消息的offset 可能被提交了，然而 A 消息在应用系统中尚未执行完毕且状态都保存在了内存中，无法保留此时重启应用将不会继续kafka 同时消费一个消息 A 消息，而是神不知鬼不觉的跳过当然这种情况也并非算得上丢失数据，重置 offset 一样可以找的回来但是手动提交 offset 可以避免这种诡异的情况发生。

官方的意思是尽可能多节點集群部署节点数尽可能大于等于3，并且 replication 数量也是大于等于3那么当 replication 数量为 N 时，ack 设置为 all这种情况下，就能确保 N-1台机子宕机的时候数據仍能保持不丢。