Kafka核心总述

Kafka核心总结

5.1Kafka消费端的Rebalance

我们知道，一个topic能被若干个消费者进行消费，若干个消费者组成一个Consumer Group消费组，一条消息只能被消费组中的一个消费者消费，但是可以被不同消费组中的不同消费者消费。
Rebalance是一个消费组的所有消费者就如何消费订阅topic的所有分区达成共识的过程，在Rebalance过程中，所有的Consumer实例都会停止消费，等待Rebalance的完成，会严重影响消费端的TPS。

5.2Kafka消费端的Rebalance发生的条件

	*当消费组的消费者成员数量发生变化的时候
	*当消费主题的数量发生变化的时候
	*斜体样式当消费主体的分区数量发生变化的时候

5.3Kafka协调器

包括broker端的组协调器（Group Coordinator）和消费端的消费者协调器（Consumer Coordinator）。
当每一个broker启动的时候都会创建一个Group Coordinator实例，负责消费组注册、消费者成员记录、offset等元数据操作。当每一个Consumer实例化时，同时会创建一个Consumer Coordinator 实例，负责消费组下各个消费者和服务端组协调器之间的通信。两端的协调器之间通过heart beat不断保持通信。

5.4如何避免Kafka消费组的Rebalance

一般就两种情况，一是我们为了提高消费速度而有新的消费者加入，比如我们增加了消费线程或者多部署了新的消费程序；另一种是由消费者的退出。
消费端参数session.timeout.ms（组协调器认为消费组存活的期限，默认3s）和heartbeat.interval.ms（消费者发送心跳的时间间隔，0.10.1之后默认10s）。我们知道，在0.10.1版本之后Kafka维护了单独的心跳线程，之前是使用业务主线程发送的心跳，另一个需要注意的是，增加了一个max.poll.interval.ms（Consunmer 两次调用poll方法拉去数据的最大时间间隔，默认5min），超过这个时间间隔将会Rebalance。
此外，如果消费端频繁的FullGC也可能导致消费端长时间停顿，从而引发Rebalance。
鉴于以上，我们应该：
	合理配置 session.timeout.ms 和 heartbeat.interval.ms
	根据实际业务调整 max.poll.interval.ms
	监控消费端的 GC 情况，避免由于频繁 FullGC 导致线程长时间停顿

附赠常见kafka面试32题（过往记忆大数据）
https://www.iteblog.com/archives/2605.html