前几天在调查一个Kafka服务器tcp连接数过大的问题。具体情况是单台Kafka的tcp连接数超过了3万，都是ESTABLISHED状态，到部分remote ip的连接数达到了几百，且连接数每天还在持续增加。这批remote ip都是属于同一个业务。
刚开始怀疑是Kafka某些条件下存在socket leakage的bug。但后来调查证实是防火墙引起的问题——Kafka服务器与这批业务服务器间存在一个防火墙，且配置了清理半小时的空闲连接。而我们使用的Kafka版本较低(0.8.2.1)，在创建连接时没有使用tcp keepalive。于是有些连接长时间没有数据传输就被防火墙在中间悄悄干掉了，而Kafka broker端没有发现，残留了大量无效连接。
其实Kafka官网已经记录了这个issue(https://issues.apache.org/jira/browse/KAFKA-2096)，解决方案就是在创建tcp连接时加上keepalive选项，在0.9.0版本中已经解决。我们的Kafka由于升级影响较大，为降低风险采取了patch回当前版本的解决方案。
之前一直没太深入了解过TCP Keepalive，借此机会补一下课，也在此简单记录。
TCP keepalive选项，在创建tcp socket时默认是不打开的。默认的发送间隔较长，为7200秒，即2小时。在linux内核中相关的配置参数为
net.ipv4.tcp_keepalive_time = 7200
net.ipv4.tcp_keepalive_intvl = 75
net.ipv4.tcp_keepalive_probes = 9
如果需要修改为更短的keepalive间隔，可以用命令
# 修改为20分钟
sysctl -w net.ipv4.tcp_keepalive_time=1200
查看一个tcp连接是否使用了keepalive，可以用netstat -o查看，最后一列会是keepalive和倒计时。
要注意tcp keepalive是单向的，即只是单向的发送keepalive包且不需要response。
一个简单例子。
server端：
nc -kl localhost 9000
client端，用python实现：
import socket
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.setsockopt(socket.SOL_SOCKET, socket.SO_KEEPALIVE, 1)
print s.getsockopt(socket.SOL_SOCKET, socket.SO_KEEPALIVE)
address = ('127.0.0.1', 9000)
s.connect(address)
连接状态：
$ netstat -npo | grep 9000
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
tcp 0 0 127.0.0.1:48532 127.0.0.1:9000 ESTABLISHED 9780/python2.7 keepalive (7184.77/0/0)
tcp 0 0 127.0.0.1:9000 127.0.0.1:48532 ESTABLISHED 27441/nc off (0.00/0/0)
从上面的最后一列可以看到，client到server的连接使用了keepalive，下次发送keepalive的倒计时为7184秒。
参考资料：
