KafkaProducer 在构建实例的时候，会在后台默默地启动一个 Sender 线程，这个 Sender 线程负责 Socket 连接的创建。并且连接 bootstrap.servers 指定的的所有 broker.
构建 KafkaConsumer 实例时是不会创建任何 TCP 连接的.
TCP 连接是在调用 KafkaConsumer.poll 方法时被创建的。
创建 TCP 连接三种情况
1.发起 FindCoordinator 请求时。
协调者（Coordinator),它驻留在 Broker 端的内存中，负责消费者组的组成员管理和各个消费者的位移提交管理。
当消费者程序首次启动调用 poll 方法时，它需要向 Kafka 集群当前负载最小的那台 Broker 发送请求发送一个名为 FindCoordinator 的请求，希望 Kafka 集群告诉它哪个 Broker 是管理它的协调者。
2.连接协调者时。
Broker 处理完上一步发送的 FindCoordinator 请求之后，会返还对应的响应结果（Response），显式地告诉消费者哪个 Broker 是真正的协调者，因此在这一步，消费者知晓了真正的协调者后，会创建连向该 Broker 的 Socket 连接。只有成功连入协调者，协调者才能开启正常的组协调操作，比如加入组、等待组分配方案、心跳请求处理、位移获取、位移提交等。
3.消费数据时。
消费者会为每个要消费的分区创建与该分区领导者副本所在 Broker 连接的 TCP。
假设消费者要消费 5 个分区的数据，这 5 个分区各自的领导者副本分布在 4 台 Broker 上，那么该消费者在消费时会创建与这 4 台 Broker 的 Socket 连接。
创建 TCP连接个数&顺序
- 确定协调者和获取集群元数据。
- 连接协调者，令其执行组成员管理操作。
- 执行实际的消息获取。
关闭 TCP
1. 手动关闭KafkaConsumer.close() 方法，或者是执行 Kill 命令，不论是 Kill -2 还是 Kill -9；
2. 自动关闭是由消费者端参数 connection.max.idle.ms 控制的，该参数现在的默认值是 9 分钟，即如果某个 Socket 连接上连续 9 分钟都没有任何请求“过境”的话，那么消费者会强行“杀掉”这个 Socket 连接。
当第三类 TCP 连接成功创建后，消费者程序就会废弃第一类 TCP 连接，之后在定期请求元数据时，它会改为使用第三类 TCP 连接。也就是说，最终你会发现，第一类 TCP 连接会在后台被默默地关闭掉。对一个运行了一段时间的消费者程序来说，只会有后面两类 TCP 连接存在。
注意: connection.max.idle.ms 设置成 -1 , 禁用定时关闭. 很有可能导致产生很多永久的 "僵尸" 连接.
引用:
Kafka核心技术与实战 - 胡夕
