首先，客户端 socket 会被设置为非阻塞模式，因为 Redis 在网络事件处理上采用的是非阻塞多路复用模型。

然后为这个socket 设置 TCP_NODELAY 属性，禁用 Nagle 算法

然后创建一个 readable 的文件事件用于监听这个客户端 socket 的数据发送

Nagle算法就是为了尽可能发送大块数据，避免网络中充斥着许多小数据块。

Nagle算法的基本定义是任意时刻，最多只能有一个未被确认的小段。 所谓“小段”，指的是小于MSS尺寸的数据块，
所谓“未被确认”，是指一个数据块发送出去后，没有收到对方发送的ACK确认该数据已收到。

Nagle算法只允许一个未被ACK的包存在于网络，它并不管包的大小，因此它事实上就是一个扩展的停-等协议，只不过它是基于包停-等的，而不是基于字节停-等的。

TCP_NODELAY 选项
默认情况下，发送数据采用Nagle 算法。这样虽然提高了网络吞吐量，但是实时性却降低了，在一些交互性很强的应用程序来说是不允许的，
使用TCP_NODELAY选项可以禁止Nagle 算法。

因为Nagle有时候会很慢：
因为TCP/IP中不仅仅有nagle算法，还有一个TCP确认延迟机制 。当Server端收到数据之后，它并不会马上向client端发送ACK，
而是会将ACK的发送延迟一段时间（假设为t），它希望在t时间内server端会向client端发送应答数据，这样ACK就能够和应答数据一起发送，
就像是应答数据捎带着ACK过去。

TCP_CORK 选项
所谓的CORK就是塞子的意思，形象地理解就是用CORK将连接塞住，使得数据先不发出去，等到拔去塞子后再发出去。
设置该选项后，内核会尽力把小数据包拼接成一个大的数据包（一个MTU）再发送出去，当然若一定时间后（一般为200ms，该值尚待确认），
内核仍然没有组合成一个MTU时也必须发送现有的数据。

Nagle算法与CORK算法区别

Nagle算法关心的是网络拥塞问题，只要所有的ACK回来则发包。避免网络因为太多的小包（协议头的比例非常大）而拥塞（其实就是避免太多包，它不关注包的大小）。

而CORK算法则是为了提高网络的利用率，使得总体上协议头占用的比例尽可能的小（它关注包的大小，希望把小包凑成大的包）。

它们的着眼点不一样。

在用户控制的层面上，Nagle算法完全不受用户socket的控制，你只能简单的设置TCP_NODELAY而禁用它，
CORK算法同样也是通过设置或者清除TCP_CORK使能或者禁用之。

当客户端连接被初始化后，Redis会查看目前的连接数，然后对比配置好的 maxclients 值，如果目前连接数已经达到最大连接数 maxclients 了，
那么说明这个连接不能再接收，Redis 会直接返回客户端一个连接错误，并马上关闭掉这个连接。

注：先建立连接，后检查，然后再断开。提高了并发量。

如果有多个客户端连接上 Redis，并且都向 Redis 发送命令，那么 Redis 服务端会先处理哪个客户端的请求呢？

答案其实并不确定，主要与两个因素有关，
一是客户端对应的 socket 对应的数字的大小，
二是 kernal 报告各个客户端事件的先后顺序。

它对触发事件的 socket 调用一次 read()，只读一次（而不是把这个 socket 上的消息读完为止），是为了防止由于某个别客户端持续发送太多命令，
导致其它客户端的请求长时间得不到处理的情况。

当然，当这一次 read()调用完成后，它里面无论包含多少个命令，都会被一次性顺序地执行。这样就保证了对各个客户端命令的公平对待。

在 Redis2.4 中，最大连接数是被直接硬编码在代码里面的，
而在2.6版本中这个值变成可配置的。
maxclients 的默认值是 10000，你也可以在 redis.conf 中对这个值进行修改。

如果系统设置的数字，小于咱们希望的最大连接数加32，那么这个 maxclients 的设置将不起作用，Redis 会按系统要求的来设置这个值。
（加32是因为 Redis 内部会使用最多32个文件描述符，所以连接能使用的相当于所有能用的描述符号减32）。

--maxclients 100000 [41422] 23 Jan 11:28:33.179 # Unable to set the max number of files limit to 100032 (Invalid argument), 
setting the max clients configuration to 10112.

ulimit -Sn 100000 # This will only work if hard limit is big enough.
sysctl -w fs.file-max=100000

可能是一个简单的命令，能够产生体积庞大的返回数据。

另外也有可能因为执行命令太多，产生的返回数据的速率超过了往客户端发送的速率，这时也会产生消息堆积，
从而造成输出缓冲区越来越大，占用过多内存，甚至导致系统崩溃。

一种是大小限制，当某一个客户端的缓冲区超过某一大小时，直接关闭掉这个客户端连接

另一种是当某一个客户端的缓冲区持续一段时间占用空间过大时，也直接关闭掉客户端连接

对普通客户端来说，限制为0，也就是不限制，因为普通客户端通常采用阻塞式的消息应答模式，如：发送请求，等待返回，再发请求，再等待返回。
这种模式通常不会导致输出缓冲区的堆积膨胀。

对于 Pub/Sub 客户端来说，大小限制是32m，当输出缓冲区超过32m时，会关闭连接。持续性限制是，当客户端缓冲区大小持续60秒超过8m，也会导致连接关闭。

而对于 Slave 客户端来说，大小限制是256m，持续性限制是当客户端缓冲区大小持续60秒超过64m时，关闭连接。

比较暴力，当客户端传输的请求大小超过1G时，服务端会直接关闭连接。

这种方式可以有效防止一些客户端或服务端 bug 导致的输入缓冲区过大的问题。

对当前的 Redis 版本来说，服务端默认是不会关闭长期空闲的客户端的。但是你可以修改默认配置来设置你希望的超时时间。
比如客户端超过多长时间无交互，就直接关闭。同理，这也可以通过 CONFIG SET 命令或者修改 redis.conf 文件来配置。

值得注意的是，超时时间的设置，只对普通客户端起作用，对 Pub/Sub 客户端来说，长期空闲状态是正常的。

另外，实际的超时时间可能不会像设定的那样精确，这是因为 Redis 并不会采用计时器或者轮训遍历的方法来检测客户端超时，而是通过一种渐近式的方式来完成，
每次检查一部分。所以导致的结果就是，可能你设置的超时时间是10s，但是真实执行的时间是超时12s后客户端才被关闭。

> client list
id=2 addr=10.117.146.21:55330 fd=6 name= age=1759348 idle=0 flags=S db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=replconf
id=35 addr=10.117.146.21:19654 fd=5 name= age=1422 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=client

addr: 客户端的TCP地址，包括IP和端口
fd: 客户端连接 socket 对应的文件描述符句柄号
name: 连接的名字，默认为空，可以通过 CLIENT SETNAME 设置
age: 客户端存活的秒数
idle: 客户端空闲的秒数
flags: 客户端的类型 (N 表示普通客户端，更多类型见 http://redis.io/commands/client-list)
omem: 输出缓冲区的大小
cmd: 最后执行的命令名称