RabbitMQ能打开的最大连接数

RabbitMQ自带了显示能够接受的最大连接数，有2种比较直观的方式：
1. rabbitmqctl命令。

1 2 3 4 5 6 7 8 9 10 11 12

n$ rabbitmqctl status Status of node 'rabbit@10-101-17-13' ... [{pid,23658}, ...... {file_descriptors, [{total_limit,924}, {total_used,10}, {sockets_limit,829}, {sockets_used,10}]}, ...... ] ...done.

2. rabbitmq_management WebUI插件。

本文关注当RabbitMQ可用连接数耗尽时客户端的影响以及如何增加最大连接数默认值。

RabbitMQ的socket连接数(socket descriptors)是文件描述符(file descriptors，fd)的一个子集。也就是说，RabbitMQ能同时打开的最大连接数和最大文件句柄数(文件系统，管道)都是受限于操作系统关于文件描述符数量的设置，两者是此消彼长的关系。初始时，可用socket描述符与可用fd数量的比率大概在0.8-0.9左右，这个值并不固定，当socket描述符有剩余时，RabbitMQ会使用尽量多的文件描述符用于磁盘文件读写。随着服务器建立越来越多的socket连接，文件句柄开始回收，数量减少。总之，RabbitMQ会优先将文件描述符用于建立socket连接，宁可牺牲频繁打开/关闭文件带来的磁盘操作性能损耗，这种取舍很容易理解，作为网络服务器，当然优先保障网络吞吐率了。因此，对于高并发连接数的多队列读写时，队列性能会稍微差那么一点，比如用RabbitMQ做RPC。

当服务器建立的socket连接已经达到限制(sockets_limit)时，服务器不再接受新连接。这里要区分清楚，RabbitMQ不再接收的是AMQP连接，而不是传输层的TCP连接，通过简单抓包分析即可清楚流程：

1 2 3 4 5 6 7 8

$ sudo tcpdump host 10.101.17.13 and port 5672 17:24:12.214186 IP 10.101.17.166.56925 > 10.101.17.13.amqp: Flags [S], seq 3319779561, win 65535, options [mss 1368,nop,wscale 5,nop,nop,TS val 1006381554 ecr 0,sackOK,eol], length 0 17:24:12.214231 IP 10.101.17.13.amqp > 10.101.17.166.56925: Flags [S.], seq 1636058035, ack 3319779562, win 14480, options [mss 1460,sackOK,TS val 24529834 ecr 1006381554,nop,wscale 5], length 0 17:24:12.218795 IP 10.101.17.166.56925 > 10.101.17.13.amqp: Flags [.], ack 1, win 4110, options [nop,nop,TS val 1006381560 ecr 24529834], length 0 17:24:12.243184 IP 10.101.17.166.56925 > 10.101.17.13.amqp: Flags [P.], seq 1:9, ack 1, win 4110, options [nop,nop,TS val 1006381583 ecr 24529834], length 8 17:24:12.243201 IP 10.101.17.13.amqp > 10.101.17.166.56925: Flags [.], ack 9, win 453, options [nop,nop,TS val 24529841 ecr 1006381583], length 0 17:24:22.247907 IP 10.101.17.166.56925 > 10.101.17.13.amqp: Flags [F.], seq 9, ack 1, win 4110, options [nop,nop,TS val 1006391550 ecr 24529841], length 0 17:24:22.284914 IP 10.101.17.13.amqp > 10.101.17.166.56925: Flags [.], ack 10, win 453, options [nop,nop,TS val 24532352 ecr 1006391550], length 0

line 2-4是TCP握手包，成功建立TCP连接。line 5开始客户端向服务器端发送AMQP协议头字符串“AMQP0091”，共8个字节，开始AMQP握手。line 6是服务器回给客户端的ack包，但未发送AMQP connection.start方法，导致客户端一直等到超时(line 7-8)，发送FIN包关闭TCP连接。至此，AMQP连接建立失败。

从客户端(Java SDK)来看上述这个过程，客户端通过ConnectionFactory实例的newConnection()方法创建一条AMQP连接。在网络层，它首先通过java.net.Socket与服务器建立一条TCP连接，发送协议协商字符串“AMQP0091”，然后启动MainLoop线程，通过封装的Frame实例来循环读取帧(readFrame())，注意readFrame()方法可能会有一个SocketTimeoutException的超时异常，这个超时时间是由socket实例setSoTimeout方法写入，默认是10s，由AMQConnection.HANDSHAKE_TIMEOUT常量指定。当超时发生在AMQP连接握手阶段时，就抛出一个SocketTimeoutException异常，发生在其他阶段(除心跳超时)时，什么都不做继续下一个循环：

1 2 3 4

Caused by: java.net.SocketTimeoutException: Timeout during Connection negotiation at com.rabbitmq.client.impl.AMQConnection.handleSocketTimeout(AMQConnection... at com.rabbitmq.client.impl.AMQConnection.access$500(AMQConnection.java:59) at com.rabbitmq.client.impl.AMQConnection$MainLoop.run(AMQConnection.java:541)

这里的socket读取超时很容易跟连接超时搞混。连接超时由ConnectionFactory实例的setConnectionTimeout()方法指定，对应着网络层Socket实例connect()方法中的timeout参数，指的是完成TCP三次握手的超时时间；而读取超时是从socket中读取字节流的等待时间，前文已经说过，由Socket实例的setSoTimeout()指定。这在各种网络库中应该很常见，比如HttpClient。

私以为这种情况下更好的设计是应该由RabbitMQ主动断开与客户端的TCP连接，减少客户端等待时间。

最后一个问题，如何增加RabbitMQ的能够同时打开的连接数。通过前文可知，最大并发连接数由此进程可打开的最大文件描述符数量（乘以一个比例系数）决定，因此只要增加单个进程可打开的文件描述符数量即可。有几个常规方法，按作用范围可以归纳为以下几类：

1. 进程级别。在启动脚本rabbitmq-server中加入ulimit -n 10240命令(假设将最大文件描述符数量设置为10240，下同)，相当于在shell中执行，由此shell进程fork出来的进程都能继承这个配置。

2. 用户级别。修改/etc/security/limits.conf文件，添加以下配置，重新登录生效：

1 2	user soft nofile 10240 user hard nofile 10240

3. 系统级别。

1	# echo 10240 > /proc/sys/fs/file-max

上述设置只是针对proc文件系统，相当于修改了操作系统的运行时参数，重启后失效。要想永久生效，需要修改/etc/sysctl.conf文件，加入配置项fs.file-max=10240。

一个进程能打开的最大文件描述符数量受限于上述三个级别配置中的最小值。理论上，系统级别的配置数值必须要大于用户级别，用户级别的要大于进程级别的，只有这样配置才是安全的，否则进程容易因为打开文件数量问题受到来自操作系统的种种限制。操作系统为什么要限制可打开的文件描述符数量？为了系统安全。因为文件描述符本质上是一种内存中的数据结构，如果不加以限制，很容易被进程无意或恶意耗尽内存，比如fork bomb。