Redis如何处理客户端连接 _Redis

文章插图

客户端的连接的建立
redis通过在TCP端口上进行监听，或者Unix socket（如果启用）的方式来接受客户端的连接。当一个新的客户端连接被接受执行以下操作：

当Redis使用非阻塞I/O复用，客户端socket设置为非阻塞状态。
socket TCP_NODELAY属性被设置确保在连接中我们不会延迟。
一个可读的文件事件被创建，因而当新的数据可以被访问时， Reids可以更快接收客户端在socket上的查询

当客户端初始化后， Redis检查我们是否还在它可以同时处理的客户端的数量限制范围内(这个是使用 maxclients 配置指令配置的，请参阅本文档的下一节获取更多的信息。
如果它因为当前已经接受了最大数量的客户端，无法接受当前的客户端， Redis将尝试发送一个错误给客户端以便让其意识到这种情况，并且立即关闭连接。即使连接被Redis立即关闭，错误信息也会返回给客户端，因为新的socket输出缓冲区一般情况下都足够放下错误信息，因而客户端内核将处理连接错误。
客户端按照什么顺序被处理
该顺序是由客户端socket文件描述符的数字大小及核心报告客户端事件的顺序决定的，因此顺序可以看成不确定的。不过Redis给客户端提供服务时会做以下两件事:

每次它从客户端socket读取新东西的时候它只执行一次 read() 系统调用，以确保当我们有多台客户端连接时，并且有一些要求高客户端以非常快的速率发送查询时，其它客户端不会因此而受到惩罚和经历一个糟糕的延时。（译者注：意思就是不读取完整个socket的消息，而是每个socket轮流读一次）
当系统调用执行完，当前缓冲中的命令不管有多少都会被顺序处理。

最大数量的客户端
在Redis 2.4中，同时处理的最大客户端数量的限制是硬编码的。
在Redis 2.6中这个限制是动态的：默认情况下为10000个客户端，除非在redis.conf中配置了maxclients配置项。
Redis通过检查内核中我们可以打开的最多的文件描述符数量，（soft limit被检查），如果限制小于最大连接客户端连接数，则加上32（这是Redis储备给内部使用的文件描述符数量），接着这个最大连接客户端的数量将被Redis修改为系统要求的值，以便符合在当前操作系统限制下的真正能够处理的客户端数量
当配置的最大客户端数目不起作用时，则日志将在启动时显示，如下面这个例子：
$ ./redis-server --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.当Redis配置处理客户的具体数量时，确认操作系统中每个进程文件描述符的限制也相应地设置成最大值是个好主意。在linux下这些限制可以在当前的会话设置，用下面的命令在系统范围内进行设置：

ulimit -Sn 100000 # 这个将只在硬限制足够大的情况下生效。
sysctl -w fs.file-max=100000

输出缓冲限制
Redis需要为每个客户端处理可变长度的输出，因为简单的命令也可能产生一个需要传送给客户端的巨大的数据量。
也可能只是客户端以较快的速度发送多个的命令产生的更多的输出，当客户端处理新消息的速度比服务端发给给它的速度还慢时，特别是Pub/Sub客户端更是如此。
这两个原因将导致客户端输出缓冲增长及内存消耗增多。因为这个原因在默认情况下Redis为不同类型的客户端设置了输出缓冲限制。当限制到达后客户端的连接将被关闭，同时事件日志记录在Redis的日志文件中。
Redis使用两种类型的限制：