Kafka 副本同步机制

为保证producer发送的数据，能可靠到指定topic，topic的每个的partition收到 producer发送的数据后，都需要向producer发送 ack（acknowledgement确认收到），如果 producer收到 ack，就会进行下一轮的发送。

ACKS 机制

在 Kafka 中，消息的 ACK（Acknowledgment，确认）机制与生产者的 acks 配置有关。acks 配置表示生产者在接收到消息后等待副本同步确认的方式，具体取值有：

• acks=0：

• • 意义：生产者在成功将消息发送给 Kafka 服务端后不等待任何确认。
  • 结果：生产者无法知道消息是否成功到达 Kafka 服务器，可能会导致消息的丢失。这种配置下，生产者不会收到任何 ACK。

• acks=1：

• • 意义：生产者在成功将消息发送给 Kafka 服务端后，等待该分区的首领节点（leader）确认。
  • 结果：生产者会收到分区首领节点的 ACK。这意味着只要分区首领节点成功接收到消息，生产者就会得到确认，而不需要等待其他副本。

• acks=all 或 acks=-1：

• • 意义：生产者在成功将消息发送给 Kafka 服务端后，等待所有分区副本确认。
  • 结果：生产者会等待分区的所有副本都成功接收到消息并确认。这是最安全的配置，因为只有当所有副本都确认接收到消息后，才认为消息被成功提交。

生产者重试机制：

Kafka 生产者在发送消息后，如果设置了等待服务器的确认（通过 acks 参数配置），会等待一定时间来收到来自服务器的确认（ack）。这个等待时间由 timeout.ms 参数控制，默认是 10000 毫秒（10秒）。

如果在等待时间内没有收到服务器的确认，生产者可以选择重试发送或者处理发送失败的逻辑。这取决于生产者的配置。通常，生产者会根据配置的重试次数和重试间隔来进行重试，以确保消息最终被成功发送。

在 Kafka 的生产者配置中，你可以找到以下与重试相关的配置项：

• retries: 定义了生产者在发送消息时的最大重试次数。
• retry.backoff.ms: 定义了两次重试之间的等待时间间隔。

ISR 机制：

Kafka根据副本同步的情况，分成了3个集合：

• AR（Assigned Replicas）：包括ISR和OSR
• ISR（In-sync Replicas）：和leader副本保持同步的副本集合，可以被认为是可靠的数据
• OSR（Out-Sync Replicas）：和Leader副本同步失效的副本集合

当 kafka 副本同步机制是所有follower都同步成功才返回 ack 给生产者时，如果有一个follower，因为某种故障，迟迟不能与leader 进行同步，那leader 就要一直等下去，直到它完成同步，才能发送ack。这个问题怎么解决呢？

Leader维护了一个动态的in-sync replica set (ISR-同步副本列表)，意为和leader保持同步的follower集合。根据follower发来的FETCH请求中的fetch offset判断ISR中的follower完成数据同步是否成功。如果follower长时间未向leader同步数据，则该follower将被踢出ISR，该时间阈值由replica.lag.time.max.ms参数设定。Leader发生故障之后，就会从ISR中选举新的leader。

• ISR(In-Sync Replicas )：与leader保持同步的follower集合
• AR(Assigned Replicas)：分区的所有副本

• • ISR是由leader维护，follower从leader同步数据有一些延迟（包括延迟时间replica.lag.time.max.ms和延迟条数replica.lag.max.messages两个维度, 当前最新的版本0.10.x中只支持replica.lag.time.max.ms这个维度），任意一个超过阈值都会把follower剔除出ISR， 存入OSR(Outof-Sync Replicas)列表，新加入的follower也会先存放在OSR中。
  • AR=ISR+OSR。