Kafka数据可靠性保障

为确保生产者能够可靠地写入指定主题中的每个分区的数据，这些分区在成功接收数据后需向生产者返回确认响应（ack）。只有当生产者接收到这一确认信号时，才会继续发送后续数据；否则，若未接收到确认，则认为传输失败，并会自动重新发送相关数据，以防止数据丢失并提升数据传输的可靠性。

- 副本数据同步方法

- Kafka采用第二种方案，因其更具优势与适用性。

为容忍n个节点故障，我们有三种不同的方法：第一种需要+副本，第二种仅需n+。由于Kafka每个分区的数据量巨大，采用第一种方案会带来严重的数据冗余和显著的存储成本增加，因此在资源利用上，第二种方案显得更为优越。

- 尽管第二种方案网络延迟较高，但对Kafka的运行影响不大。

Leader节点维持了一个动态的同步副本集合（ISR），即与Leader保持数据一致性的follower列表。当Follower成功从Leader复制过来的数据后，Leader会向其发送确认应答（ack）。若某个Follower在设定时间内未能及时拉取并同步最新的信息，将被移出ISR，这一时间段由参数replica.lag.time.max.ms控制。只有位于ISR中的副本才有资格参与新的Leader选举。一旦当前的Leader出现故障，系统会自动从ISR中挑选一个健康的follower升级为新的Leader，以保证分区的高可用性和数据的一致性。这种机制有效地平衡了数据安全与集群性能之间的关系。

- 确认应答机制

对于次要数据，低可靠性要求，允许一定程度的丢失，故无需等所有follower同步完成即提交处理。

Kafka为用户提供三种可靠性选项，依据延迟与可靠性要求灵活配置。

- 配置acks参数

生产者发送消息无需等待代理确认，可实现最高的延迟。当代理处理消息未写入磁盘前就回传响应，而代理故障则可能造成数据损失。

生产者收到代理的确认信号，分区主副本数据已安全存储到磁盘，并及时发出。如主副本因故障在从副本未完成同步时失效，则之前未同步的数据将不可恢复，造成数据损失。

当配置为-，消费者需等待Broker的确认。此时，分区的Leader与Follower均需将数据成功写入磁盘后，才返回确认信息。然而，在Follower完成数据同步后、Broker发送确认之前，如果Leader突然发生故障，系统可能触发重新选举。新的Leader接替后，消费者可能会因为未收到确认而重发消息，从而导致数据重复写入，引发潜在的数据一致性问题。

- 故障处理具体步骤

- LEO代表各副本中最大的偏移量。

- HW指消费者可见的最大偏移量，即同步副本集中最小的日志末端偏移。