目录
概述
本文对
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
列表的副本都同步了才可以发送成功响应。
版权归原作者 流月up 所有， 如有侵权，请联系我们删除。