微服务架构之–消息队列Kafka图解最全知识点(2)

吞吐性&&延时：

• buffer.memory：buffer设置大了有助于提升吞吐性，但是batch太大会增大延迟，可搭配linger_ms参数使用
• linger_ms：如果batch太大，或者producer qps不高，batch添加的会很慢，我们可以强制在linger_ms时间后发送batch数据
• ack：producer收到多少broker的答复才算真的发送成功
• 0表示producer无需等待leader的确认(吞吐最高、数据可靠性最差)
• 1代表需要leader确认写入它的本地log并立即确认
• -1/all 代表所有的ISR都完成后确认(吞吐最低、数据可靠性最高)

Sender线程和长连接

每初始化一个producer实例，都会初始化一个Sender实例，新增到broker的长连接。

代码角度：每初始化一次KafkaProducer，都赋一个空的client

public KafkaProducer(final Map configs) { 
this(configs, null, null, null, null, null, Time.SYSTEM); 
} 

终端查看TCP连接数：

lsof -p portNum -np | grep TCP，适当增大producer数量能提升吞吐 

Consumer设计原理

poll消息

• 消费者通过fetch线程拉消息(单线程)
• 消费者通过心跳线程来与broker发送心跳。超时会认为挂掉
• 每个consumer group在broker上都有一个coordnator来管理，消费者加入和退出，以及消费消息的位移都由coordnator处理。

位移管理

consumer的消息位移代表了当前group对topic-partition的消费进度，consumer宕机重启后可以继续从该offset开始消费。在kafka0.8之前，位移信息存放在zookeeper上，由于zookeeper不适合高并发的读写，新版本Kafka把位移信息当成消息，发往__consumers_offsets 这个topic所在的broker，__consumers_offsets默认有50个分区。消息的key 是groupId+topic_partition,value 是offset.

Kafka Group 状态

• Empty：初始状态，Group 没有任何成员，如果所有的 offsets 都过期的话就会变成 Dead
• PreparingRebalance：Group 正在准备进行 Rebalance
• AwaitingSync：Group 正在等待来 group leader 的 分配方案
• Stable：稳定的状态(Group is stable);
• Dead：Group 内已经没有成员，并且它的 Metadata 已经被移除
• 注意

重平衡reblance

当一些原因导致consumer对partition消费不再均匀时，kafka会自动执行reblance，使得consumer对partition的消费再次平衡。

什么时候发生rebalance?：

• 组订阅topic数变更
• topic partition数变更
• consumer成员变更
• consumer 加入群组或者离开群组的时候
• consumer被检测为崩溃的时候

reblance过程

举例1 consumer被检测为崩溃引起的reblance

比如心跳线程在timeout时间内没和broker发送心跳，此时coordnator认为该group应该进行reblance。接下来其他consumer发来fetch请求后，coordnator将回复他们进行reblance通知。当consumer成员收到请求后，只有leader会根据分配策略进行分配，然后把各自的分配结果返回给coordnator。这个时候只有consumer leader返回的是实质数据，其他返回的都为空。收到分配方法后，consumer将会把分配策略同步给各consumer

举例2 consumer加入引起的reblance

1. 使用join协议，表示有consumer 要加入到group中
2. 使用sync 协议，根据分配规则进行分配

(上图图片摘自网络)

引申：以上reblance机制存在的问题

在大型系统中，一个topic可能对应数百个consumer实例。这些consumer陆续加入到一个空消费组将导致多次的rebalance;此外consumer 实例启动的时间不可控，很有可能超出coordinator确定的rebalance timeout(即max.poll.interval.ms)，将会再次触发rebalance，而每次rebalance的代价又相当地大，因为很多状态都需要在rebalance前被持久化，而在rebalance后被重新初始化。

新版本改进

通过延迟进入PreparingRebalance状态减少reblance次数

新版本新增了group.initial.rebalance.delay.ms参数。空消费组接受到成员加入请求时，不立即转化到PreparingRebalance状态来开启reblance。当时间超过group.initial.rebalance.delay.ms后，再把group状态改为PreparingRebalance(开启reblance)。实现机制是在coordinator底层新增一个group状态：InitialReblance。假设此时有多个consumer陆续启动，那么group状态先转化为InitialReblance，待group.initial.rebalance.delay.ms时间后，再转换为PreparingRebalance(开启reblance)

Broker设计原理

Broker 是Kafka 集群中的节点。负责处理生产者发送过来的消息，消费者消费的请求。以及集群节点的管理等。由于涉及内容较多，先简单介绍，后续专门抽出一篇文章分享

broker zk注册

（编辑：ASP站长网）