Kafka 采用了多种机制来确保数据的一致性和持久性。以下是一些关键措施来避免数据丢失：
ISR（In-Sync Replicas）机制
Kafka 维护了一个称为 ISR（In-Sync Replicas）的列表，这个列表包含了与 Leader 保持同步的所有副本。ISR 列表中的副本被认为是健康的，能够及时从 Leader 复制数据。
如何维护 ISR？
- 心跳机制：Follower 会定期向 Leader 发送心跳消息，并请求数据。如果 Follower 在一定时间内未能完成数据复制并向 Leader 发送确认，它将从 ISR 中移除。
- 数据确认：Leader 在收到 Follower 的确认信息后，才会更新 High Watermark（HW），表示这部分数据已经被所有 ISR 确认。
配置参数调整
通过调整 Kafka 的配置参数，可以进一步增强数据的持久性和一致性：
- replica.lag.time.max.ms：设置 Follower 被认为与 Leader 同步的最大延迟时间。如果 Follower 在这个时间内没有接收到数据或发送确认信息，它将从 ISR 中移除。
- min.insync.replicas：设置最小的 ISR 副本数量。如果 ISR 的数量低于这个阈值，Leader 将不会接受新的写入请求，直到有足够的副本重新同步。
数据持久化
- Leader 的数据持久化：Leader 在写入数据到日志之前，会先将数据写入到操作系统缓存（OS Cache），然后同步到磁盘。这样即使 Leader 宕机，数据也不会丢失。
- Follower 的数据持久化：Follower 在接收到数据后，同样会将数据写入到 OS Cache，然后同步到磁盘。
控制消息的确认级别
Kafka 允许控制消息的确认级别，从而确保数据的持久性：
- acks=all：这个配置意味着只有当所有 ISR 副本都确认接收到消息后，生产者才会收到确认。这提供了最高的数据保证，但可能会降低性能。
- acks=1：这个配置意味着只要有至少一个副本（通常是 Leader）确认接收到消息，生产者就会收到确认。这提供了较快的性能，但数据持久性较低。
- acks=0：这个配置意味着生产者在发送消息后立即收到确认，不等待任何副本的确认。这提供了最快的性能，但数据持久性最低。