概述

   本文对 kafka 的一些核心概念进行解释，也是 kafka 需要调优的一些地方。

官方原文速递

Replication(分区副本)

  对于每个分区，存在一个 leader 和 n 个 follower 。控制分区中 leader与 follower（1+N）数量的配置是 replication.factor。表示数据在 kafka 集群中数据副本数。默认及推荐的建议是3。

  kafka 中的分区副本两种类型：leader 与 follower ；follower 是不对外提供服务的，所有的请求都必须由 leader来处理。

In-sync replicas

   broker 上分区的最新同步副本（ISR）， 一个 leader 的副本一直是最新的 。只有当一个 follower 完全与 leader 一致时，它才是同步副本。换句话说，它不能落后于给定分区的最新记录。
如果一个 follower 落后于分区的最新数据，将不再将其视为同步副本。请参见图2，其中显示Broker3落后（不同步）。

总结：

• 所说的同步不是指完全的同步，即并不是 follower 副本同步滞后于 leader 副本，就会被踢出 ISR 列表
• kafka的 broker 端有一参数 replica.lag.time.max.ms ，表示 follower 副本与 leader 滞后的最长时间间隔，默认是 10s 。
• 如果 follower 副本被踢出 ISR 列表，等追上了 leader 副本的进度 ，会再次加入 ISR 列表，所以 ISR 是一个动态列表。
  
  注意：一般某个 follower 落后，可能是满负载，或者空间不足。

Acknowledgements

  acks 设置是在客户端（生产者）配置。表示 brokers 接受到写入成功的信息 。它支持三个值：0、1和 all 。

acks=0

  如果值为 0，生产者不会等待 broker 的响应。在 消息 发出的那一刻 ，就认为是写入成功。（见图3：生产者甚至不等待响应。消息已被确认！）

acks=1

  设置为1，当 leader 收到记录时那一刻，则认为写入成功，不再等待。（见图4：生产者等待响应。一旦收到响应，消息就会得到确认。broker 在收到记录后立即响应。followers 异步复制新记录。）

acks=all

  当设置为all时，当所有同步副本都收到记录时，此时生产者将认为写入成功。这是通过 leader broker 在响应请求时来实现的——一旦所有同步副本都收到记录，它就会发回响应。（见图5：没那么快！Broker 3还没有收到记录。）

当 leader broker 知道所有 followers 都同步完

Ack实用建议

  正如上面总结的那样，需要在性能与数据可靠性之间做平衡，如果想要保证数据准确与安全，配置 all ；如果想要保证性能，丢失一些数据，无影响 ，使用 0，来获得极致的性能、低延迟，高吞吐。

Minimum in-sync replica

  当 acks=all 时，需要所有的副本都同步了才会发送成功响应到生产者，这里面存在一个问题：如果 leader 副本是唯一的同步副本时，相当于 acts=1 ，所以是不安全的。
  kafka的 broker 端提供了 min.insync.replicas ，该参数控制的是消息至少被写入到多少个副本才算是 真正的写入，默认值 1 ，生产环境设定一个大于 1 的值可以提升消息的持久性。因为如果同步副本的数量低于该配置值 ，则生产者会收到错误响应，从而确保消息不丢失。
  请看下图，Broker2 同步成功，Broker3 没有同步成功，且不在 ISR 列表中，此时min.insync.replicas=2 表示消息发送成功 。

  下图对 acks=all 和 acks=1 时，同是 min.insync.replicas=2 条件下发送消息，ACK 是不一样的。

Caveat(警告)

  这种情况容易引起误解。如果 acks=all 且 min.insync.replicas=2 ，此时 ISR 列表为 [1,2,3]，那么还是会等到所有的同步副本都同步了消息，才会向生产者发送响应的 ack。因为 min.insync.replicas=2 只是一个最低限制，即同步副本少于该值配置值 ，则会抛出异常，而 acks=all 是需要保证所有的 ISR 列表的副本都同步了才可以发送成功响应。