日常梳理-kafka/zookeeper使用

生产者参数

生产者参数
buffer.memory	默认32M	内存缓冲大小 通过KafkaProducer发送出去的消息都是先进入到客户端本地的内存缓冲里，然后把很多消息收集成一个一个的Batch，再发送到Broker上去的。
batch.size	默认16K	ProducerBatch的大小
linger.ms	默认0	生产者客户端会在ProducerBatch被填满或等待时间超过linger.ms值时发送出去。
max.request.size	默认1M	最大请求大小 1）限制单条消息大小 2）限制每次发送给Kafka服务器请求的最大大小
retries和retries.backoff.ms	重试机制	retries 请求重试次数 retries.backoff.ms 每次重试的间隔时间
acks	默认1	1）acks=1 生产者发送消息之后，只要分区的leader副本成功写入消息，那么它就会收到 来自服务端的成功响应。 2）acke=0 生产者发送消息之后不需要等待任何服务器的响应 3）acks=-1或acks=all 生产者在消息发送之后，需要等待ISR中的所有副本都成功写入消息之后才能够收到来自服务器的成功响应。
max.in.flight.requests.per.connection	默认5	限制每个连接最多缓存的未响应请求数，超过该值之后就不能再向这个连接发送更多的请求了，除非有缓存的请求收到了响应。 涉及分区的有序性，设置为1可以保证有序性，但是发送性能会受影响。不为1的时候，如果发生消息重发则会乱序

消费者参数

消费者参数
max.partition.fetch.bytes	默认1MB(1048576)。 指定了服务器从每个分区里返回给消费者的最大字节数。消费者poll()从每个分区里返回的记录最大不超过该值。	(一条msg大小)*（max.poll.records）<=(max.partition.fetch.bytes)
max.poll.records	默认500 Consumer每次调用poll()时取到的records的最大数。	如果数量过多，导致一次poll操作返回的消息记录无法在指定时间内完成，则会触发rebalace
heartbeat.interval.ms	默认值3000，即3秒 消费者的心跳间隔时间	消费者是通过向GroupCoordinator发送心跳来维持它们与消费组的从属关系，以及它们对分区的所有权关系。心跳线程是独立的线程。 这个参数必须 比session.timeout.ms参数设定的值要小，一般情况下值不能超过session.timeout.ms配置值的1/3
session.timeout.ms	默认值10000，即10秒 组管理协议中用来检测消费者是否失效的超时时间。	GroupCoordinator超过session_timeout指定的时间内没有收到心跳报文则认为该消费者已经下线。 该值必须在broker端参数group.min.session.timeout.ms(默认值为6000，即6秒)和group.max.session.timeout.ms(默认值为300000，取5分钟)允许的范围内。
max.poll.interval.ms	默认300000，取5分秒 两个poll操作间隔的最大时间	当通过消费组管理消费者时，该配置指定拉取消息线程最长空闲时间，若超过这个时间间隔还没有发起poll操作，则消费组认为该消费者已离开了消费组，将进行再均衡操作。Rebalance
fetch.min.bytes	默认1B 配置poll拉取请求过程中能从kafka拉取的最小数据量，如果可用数据量小于该值，会等到有足够数据时才会返回给消费者
fetch.max.bytes	默认50MB（52428800） 表示服务端能返回消息的总大小
enable.auto.commit	当为true，采用kafka的默认提交模式。 当为false，采用springr的人工提交模式。
auto.commit.interval.ms	默认5000，即5秒 自动提交间隔时间
auto.offset.reset	earliest：当各分区下有已提交的offset时，从提交的offset开始消费；无提交的offset时，从头开始消费 latest:当各分区下有已提交的offset时，从提交的offset开始消费；无提交的offset时，消费新产生的该分区下的数据 默认为lastest。

kafka 中 zookeeper 具体是做什么的？

broker:

管理kafka的元数据信息：

​ broker列表

​ topic的相关配置，例如 topic 列表、每个 topic 的 partition 数量、副本的位置等等。

控制器选举：

​ kafka 集群中有多个 broker，其中有一个会被选举为控制器。

​ 控制器负责管理整个集群所有分区和副本的状态，例如某个分区的 leader 故障了，控制器会选举新的 leader。

​ 从多个 broker 中选出控制器，这个工作就是 zookeeper 负责的。

记录ISR

​ ISR（in-sync replica） 是 partition 的一组同步集合，就是所有 follower 里面同步最积极的那部分。

​ 一条消息只有被 ISR 中的成员都接收到，才被视为“已同步”状态。

​ 只有处于 ISR 集合中的副本才有资格被选举为 leader。

​ zookeeper 记录着 ISR 的信息，而且是实时更新的，只要发现其中有成员不正常，马上移除。

consumer:

​ consumer会注册到zookeeper

​ 分区注册：kafka 的每个 partition 只能被消费组中的一个 consumer 消费，kafka 必须知道所有 partition 与 consumer 的关系。

通过zookeeper客户端查看相关信息

controller控制器

[zk: localhost:2181(CONNECTED) 26] get /controller
{"version":1,"brokerid":0,"timestamp":"1614043960487"}
cZxid = 0x2f00000020
ctime = Tue Feb 23 09:32:40 CST 2021
mZxid = 0x2f00000020
mtime = Tue Feb 23 09:32:40 CST 2021
pZxid = 0x2f00000020
cversion = 0
dataVersion = 0
aclVersion = 0
ephemeralOwner = 0x277cc837f12000f
dataLength = 54
numChildren = 0

controller_epoch: 表示kafka集群中的中央控制器选举次数

[zk: localhost:2181(CONNECTED) 24] get /controller_epoch
360
cZxid = 0x200000018
ctime = Sun Aug 23 17:57:37 CST 2020
mZxid = 0x2f00000021
mtime = Tue Feb 23 09:32:40 CST 2021
pZxid = 0x200000018
cversion = 0
dataVersion = 359
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 3
numChildren = 0

ISR（in-sync replica） 是 partition 的一组同步集合

[zk: localhost:2181(CONNECTED) 18] get /brokers/topics/trace-log-queue/partitions/1/state
{"controller_epoch":360,"leader":0,"version":1,"leader_epoch":509,"isr":[0,2]}
cZxid = 0x600000326
ctime = Sun Sep 20 11:00:15 CST 2020
mZxid = 0x2f000000d4
mtime = Tue Feb 23 09:33:03 CST 2021
pZxid = 0x600000326
cversion = 0
dataVersion = 989
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 78
numChildren = 0