为确保生产者发送的数据能够被可靠地写入指定主题，每个分区在成功接收数据后，必须向生产者返回确认响应（ack）。只有当生产者接收到该确认信号，才会继续发送下一批数据；若未收到确认，生产者将认为发送失败，并自动重发数据，从而避免数据丢失，提升传输的可靠性。
1、 副本数据同步方式
2、 Kafka选用第二种方案，因其在实际应用中具备更高的优势和适用性。
3、 为了容忍n个节点故障，第一种方案需要配置2n+1个副本，而第二种仅需n+1个。由于Kafka中每个分区可能存储大量数据，若采用第一种方式会造成显著的数据冗余，大幅增加存储成本。因此，从资源利用效率来看，第二种方案更具优势。
4、 尽管第二种方案在网络延迟方面略高，但对Kafka整体运行性能影响较小，可接受性强。
5、 Leader节点会维护一个动态的同步副本集合（ISR），即与Leader保持数据同步的Follower列表。当Follower成功复制Leader上的新消息后，Leader会向其发送确认应答（ack）。如果某个Follower在规定时间内未能及时拉取并同步最新数据，则会被移出ISR，这一超时阈值由参数replica.lag.time.max.ms控制。只有位于ISR中的副本才有资格参与Leader选举。一旦当前Leader发生故障，系统将自动从ISR中选择一个健康的Follower升级为新的Leader，保障分区的高可用性和数据一致性。该机制有效平衡了数据安全与系统性能之间的关系。
6、 确认应答机制详解
7、 对于重要性较低的数据，允许一定程度的丢失，无需等待所有ISR内的Follower完成同步即可提交，以提高吞吐量。
8、 Kafka提供了三种不同的可靠性级别，用户可根据业务对延迟和可靠性的要求进行权衡，选择合适的配置策略。
9、 acks参数配置说明
10、 当acks设置为0时，生产者发送消息后不等待Broker的任何确认，延迟最低。此时即使Broker仅接收到消息但尚未持久化到磁盘就返回响应，若Broker随后发生故障，可能导致数据永久丢失。
11、 当acks设置为1时，生产者会等待Broker的确认。只要分区的Leader副本成功将数据写入磁盘，就会立即返回确认。但如果此时Follower还未完成同步，Leader即发生故障，则未同步的数据将无法恢复，造成数据丢失。
12、 当acks设置为-1（或all）时，生产者需等待所有ISR中副本的确认。只有当Leader和所有ISR内的Follower都将数据成功写入磁盘后，才向生产者返回确认。然而，若在Follower完成同步后、Broker返回确认前，Leader突然宕机，系统将触发重新选举。新当选的Leader可能并未包含此次已同步但未确认的消息，而生产者因未收到确认而重发消息，导致消息重复写入，带来潜在的数据重复问题。
13、 故障处理流程说明
14、 LEO（Log End Offset）表示各个副本当前日志中最大的偏移量，即下一个待写入的位置。
15、 HW（High Watermark）代表消费者可以读取到的最大偏移量，其值等于所有ISR副本中最小的LEO。只有小于HW的消息才被视为已提交，对消费者可见。
