目录
概述
本文对 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
列表的副本都同步了才可以发送成功响应。