在Kafka中，TCP连接的管理交由底层的Selector类(org.apache.kafka.common.network)来维护。Selector类定义了很多数据结构，其中最核心的当属java.nio.channels.Selector实例，故所有的IO事件实际上是使用Java的Selector来完成的。本文我们探讨一下producer与Kafka集群进行交互时TCP连接的管理与维护。

一、何时创建TCP连接

Producer端在创建KafkaProducer实例时就会创建与broker的TCP连接——这个表述严格来说不是很准确，应当这么说：在创建KafkaProducer实例时会创建并启动Sender线程实例。Sender线程开始运行时首先就会创建与broker的TCP连接，如下面这段日志所示：

[2018-12-09 09:35:45,620] DEBUG [Producer clientId=producer-1] Initialize connection to node localhost:9093 (id: -2 rack: null) for sending metadata request (org.apache.kafka.clients.NetworkClient:1084)
[2018-12-09 09:35:45,622] DEBUG [Producer clientId=producer-1] Initiating connection to node localhost:9093 (id: -2 rack: null) using address localhost/127.0.0.1 (org.apache.kafka.clients.NetworkClient:914)

[2018-12-09 09:35:45,814] DEBUG [Producer clientId=producer-1] Initialize connection to node localhost:9092 (id: -1 rack: null) for sending metadata request (org.apache.kafka.clients.NetworkClient:1084)
[2018-12-09 09:35:45,815] DEBUG [Producer clientId=producer-1] Initiating connection to node localhost:9092 (id: -1 rack: null) using address localhost/127.0.0.1 (org.apache.kafka.clients.NetworkClient:914)

[2018-12-09 09:35:45,828] DEBUG [Producer clientId=producer-1] Sending metadata request (type=MetadataRequest, topics=) to node localhost:9093 (id: -2 rack: null) (org.apache.kafka.clients.NetworkClient:1068)

在我的样例代码中，bootstrap.servers指定了"localhost:9092, localhost:9093"。由上面的日志可以看到KafkaProducer实例创建后（此时尚未开始发送消息）producer会创建与这两台broker的TCP连接。特别注意我标红的broker id——这里的id都是负值，我会在后文详细说说这里面的事情。 另外，上述日志中最后一行表明producer选择了向localhost:9093的broker发送METADATA请求去获取集群的元数据信息——实际上producer选择的是当前负载最少的broker。这里的负载指的是未处理完的网络请求数。

总的来说，TCP连接是在Sender线程运行过程中创建的，所以即使producer不发送任何消息（即显式调用producer.send），底层的TCP连接也是会被创建出来的。

在转到下一个话题之前，我想聊聊针对这种设计的一些自己的理解：如社区文档所说，KafkaProducer类是线程安全的。我虽然没有详尽地去验证过是否真的thread-safe，但根据浏览源码大致可以得出这样的结论：producer主线程和Sender线程共享的可变数据结构大概就只有RecordAccumulator类，因此维护RecordAccumulator类的线程安全也就实现了KafkaProducer的线程安全，而RecordAccumulator类中主要的数据结构是ConcurrentMap<TopicPartition, Deque<ProducerBatch>>，而且凡是用到Deque的地方基本上都由Java monitor lock来保护，所以基本上可以认定RecordAccumulator的线程安全性。

我这里真正想说的是，即使KafkaProducer类是线程安全的，我其实也不太赞同创建KafkaProducer实例时立即启动Sender线程的做法。Brian Goetz大神著作《Java Concurrency in Practice》中明确给出了这样做的风险：在对象构造器中启动线程会造成this指针的逃逸——理论上Sender线程完全能够看到一个未构造完整的KafkaProducer实例。当然在构造KafkaProducer实例时创建Sender线程实例本身没有任何问题，但最好不要启动它。

二、 创建多少个TCP连接

我们还是结合日志来看。这次producer开始发送消息，日志如下：

[2018-12-09 10:06:46,761] DEBUG [Producer clientId=producer-1] 开始发送消息...
[2018-12-09 10:06:46,762] DEBUG [Producer clientId=producer-1] Initialize connection to node localhost:9092 (id: 0 rack: null) for sending metadata request (org.apache.kafka.clients.NetworkClient:1084)
[2018-12-09 10:06:46,762] DEBUG [Producer clientId=producer-1] Initiating connection to node localhost:9092 (id: 0 rack: null) using address localhost/127.0.0.1 (org.apache.kafka.clients.NetworkClient:914)

[2018-12-09 10:06:46,765] DEBUG [Producer clientId=producer-1] Initialize connection to node localhost:9093 (id: 1 rack: null) for sending metadata request (org.apache.kafka.clients.NetworkClient:1084)
[2018-12-09 10:06:46,766] DEBUG [Producer clientId=producer-1] Initiating connection to node localhost:9093 (id: 1 rack: null) using address localhost/127.0.0.1 (org.apache.kafka.clients.NetworkClient:914)

[2018-12-09 10:06:46,770] DEBUG [Producer clientId=producer-1] Sending metadata request (type=MetadataRequest, topics=test) to node localhost:9092 (id: 0 rack: null) (org.apache.kafka.clients.NetworkClient:1068)

日志告诉我们，producer又创建了与localhost:9092、localhost:9093的TCP连接。加上最开始创建的两个TCP连接，目前producer总共创建了4个TCP连接，连向localhost:9092和localhost:9093各有两个。再次注意标红的broker id——此时id不再是负值了，或者说此时它们是真正的broker id了（即在server.properties中broker.id指定的值）。这个结论告诉了我们一个有意思的事实：当前版本下(2.1.0)，Kafka producer会为bootstrap.servers中指定的每个broker都创建两个TCP连接：第一个TCP连接用于首次获取元数据信息；第二个TCP连接用于消息发送以及之后元数据信息的获取。注意，第一个TCP连接中broker id是假的；第二个TCP连接中broker id才是真实的broker id。

另外，注意上面日志的最后一行。当producer再次发送METADATA请求时它使用的是新创建的TCP连接，而非最开始的那个TCP连接。这点非常关键！这揭示了一个事实：最开始创建的TCP连接将不再被使用，或者说完全被废弃掉了。

三、何时关闭 TCP连接

Producer端关闭TCP连接的方式有两种：一种是用户主动关闭；一种是Kafka自动关闭。我们先说第一种，这里的主动关闭实际上是广义的主动关闭，甚至包括用户调用kill -9主动“杀掉”producer应用。当然最推荐的方式还是调用producer.close方法来关闭。第二种则是Kafka帮你关闭，这与producer端参数connections.max.idle.ms的值有关。默认情况下该参数值是9分钟，即如果在9分钟内没有任何请求“流过”该某个TCP连接，那么Kafka会主动帮你把该TCP连接关闭。用户可以在producer端设置connections.max.idle.ms=-1禁掉这种机制。一旦被设置成-1，TCP连接将成为永久长连接。当然这只是软件层面的“长连接”机制，由于Kafka创建的这些Socket连接都开启了keepalive，因此keepalive探活机制还是会遵守的。

四、可能的问题？

显然，这种机制存在一个问题：假设你的producer指定了connections.max.idle.ms = -1（因为TCP连接的关闭与创建也是有开销的，故很多时候我们确实想要禁掉自动关闭机制）而且bootstrap.servers指定了集群所有的broker连接信息。我们假设你的broker数量是N，那么producer启动后它会创建2 * N个TCP连接，而其中的N个TCP连接在producer正常工作之后再也不会被使用且不会被关闭。实际上，producer只需要N个TCP连接即可与N个broker进行通讯。为了请求元数据而创建的N个TCP连接完全是浪费——我个人倾向于认为Kafka producer应该重用最开始创建的那N个连接，因此我觉得这是一个bug。

造成重复创建TCP连接的根本原因在于broker id的记录。就像之前说到的，最开始producer请求元数据信息时它肯定不知道broker的id信息，故它做了一个假的id（从-1开始，然后是-2， -3。。。。），同时它将这个id保存起来以判断是否存在与这个broker的TCP连接。Broker端返回元数据信息后producer获知了真正的broker id，于是它拿着这个broker id去判断是否存在与该broker的TCP连接——自然是不存在，因此它重新创建了一个新的Socket连接。这里的问题就在于我们不能仅仅依靠broker id来判断是否存在连接。实际上使用host:port对来判断可能是更好的方法。也许社区可以考虑在后续修正这个问题。

简单总结一下当前的结论，针对最新版本Kafka（2.1.0）而言，Java producer端管理TCP连接的方式是：

1. KafkaProducer实例创建时启动Sender线程，从而创建与bootstrap.servers中所有broker的TCP连接

2. KafkaProducer实例拿到元数据信息之后还会再次创建与bootstrap.servers中所有broker的TCP连接

3. 步骤1中创建的TCP连接只用于首次获取元数据信息（实际上也只是会用到其中的一个连接，其他的N - 1个甚至完全不会被用到）

4. 如果设置producer端connections.max.idle.ms参数大于0，则步骤1中创建的TCP连接会被自动关闭；如果设置该参数=-1，那么步骤1中创建的TCP连接将成为“僵尸”连接

5. 当前producer判断是否存在与某broker的TCP连接依靠的是broker id，这是有问题的，依靠<host, port>对可能是更好的方式