TCP中backlog简介
Linux内核为每个TCP服务器程序维护两条backlog队列，一条是TCP层的未连接队列，一条是应用层的已连接队列，分别对应net.ipv4.tcp_max_syn_backlog和net.core.somaxconn两个内核参数。
一个客户端连接在完成TCP 3次握手之前首先进入到未连接队列，完成握手之后正式建立连接，进入已连接队列，交付给应用程序处理。应用程序调用accept()函数从已连接队列取出连接进行处理。应用层在调用listen()函数时指定的backlog是已连接队列大小，如果大于somaxconn将被设为somaxconn。
如果应用层不调用accept()函数处理一个连接，或者处理不及时的话，将会导致已连接队列堆满。已连接队列已满的话会导致未连接队列在处理完3次握手之后无法进入已连接队列，最终也导致未连接队列堆满，在服务器看到处于未连接队列中的连接状态为SYN_RECV。 新进来的客户端连接将会一直处于SYN_SENT状态等待服务器的ACK应答，最终导致连接超时。
查看队列大小：
查看未连接队列默认值：
cat /proc/sys/net/ipv4/tcp_max_syn_backlog
查看已连接队列默认值：
cat /proc/sys/net/core/somaxconn
修改队列大小：
可以直接改写这两个文件的值。要永久修改这两个内核参数的话可以写到/etc/sysctl.conf：
net.ipv4.tcp_max_syn_backlog = 1024
net.core.somaxconn = 1024
改完后执行sysctl -p 让修改立即生效。
案例
转http://www.tuicool.com/articles/qeQZryM
一、周期性出现connect timeout:
1. 背景：
大部分互联网公司都会有Mysql或者Oracle的DBA，但是在Nosql方面一般不会设置专门的DBA。不过对于一些知名的互联网公司来说，Nosql的使用量是巨大的，所以通常让Mysql的DBA或者单独聘请工程师来维护一些Nosql数据库，比如:
Redis, Hbase, Memcache(其实严格讲不是nosql), Mongodb, Cassandra。从讲座看美团网应该是有专职的Redis DBA。所以作为业务开发人员不需要自己安装、配置、运维Redis，只需要找Redis DBA来申请就可以了。
这里为了简化说明：Redis DBA提供的服务叫做Redis云，业务开发人员叫做业务端（redis的使用者）
2. 现象：
业务端在使用redis云提供的redis服务后，经常出现connect timeout：
redis.clients.jedis.exceptions.JedisConnectionException java.net.SocketException java.net.SocketTimeoutException:connect time out
3. 分析和怀疑：
业务端一般认为redis出现问题，就是redis云有问题，人的“正常”思维：看别人错误容易，发现自己难，扯多了, 出现这个有很多原因：
(1). 网络原因：比如是否存在跨机房、网络割接等等。
(2). 慢查询，因为redis是单线程，如果有慢查询的话，会阻塞住之后的操作。
(3). value值过大？比如value几十兆，当然这种情况比较少，其实也可以看做是慢查询的一种
(4). aof重写/rdb fork发生？瞬间会堵一下Redis服务器。
(5). 其他..................
4. 查询原因
演讲者一开始怀疑是网络问题，但是并未发现问题，观察各种对比图表，tcp listenOverFlow和timeout经常周期出现。（赞一下这个监控，我们监控现在还没有这个层面的）
有关listenOverFlow:
查看现有的连接数是否大于设置的backlog，如果大于就丢弃，并相应的参数值加1。其中backlog是由程序和系统参数net.core.somaxconn共同设置，当backlog的值大于系统设置的net.core.somaxconn时则取net.core.somaxconn的值，否则取程序设置的backlog值。这种出错的方式也被记录在TcpListenOverflows中（其只记录了连接个数不足而产生溢出错误的次数！）。
觉得可能和TCP相关，于是分析了Tcp三次握手：最后一次握手客户端的请求会进入服务器端的一个队列（可以认为是下三图）中，如果这个队列满了，就会发生上面的异常。(accept)
(1) TCP三次握手：
(2) redis客户端与redis服务器交互的过程（本质就是TCP请求）
(3) I/O 多路复用程序通过队列向文件事件分派器传送套接字的过程
(4) 和redis有什么关系呢?
由于Redis的单线程模型（对命令的处理和连接的处理都是在一个线程中），如果存在慢查询的话，会出现上面的这种情况，造成新的accept的连接进不了队列。
如果上面的图没法理解的话，看看这张图：
5. 解决方法：
(1) 对慢查询进行持久化，比如定时存放到mysql之类。（redis的慢查询只是一个list，超过list设置的最大值，会清除掉之前的数据，也就是看不到历史）
(2) 对慢查询进行报警（频率、数量、时间）等等因素
(3) 打屁股。
(4) 其实应该做的是：对业务端进行培训，告诉他们一下redis开发的坑，redis不是万金油，这个和Mysql DBA要培训Mysql使用者一样，否则防不胜防。
比如他执行了 monitor, keys *, flushall, drop table, update table set a=1; 这种也是防不胜防的（当然也可以做限制），但是提高工程师的水平才是关键。