RabbitMQ——最大连接数

默认情况下，rabbitmq文件句柄数设置是1024。连接数最多为829，连接数的具体计算方式为：

连接数=（文件句柄数-100）*0.9，计算后的值取整再减2。

例如：（1024-100）*0.9=831.6，取整831再减2得到829。

真正使用时，1024可能无法满足实际需求。这个时候，一般通过ulimit来调整程序的最大文件句柄数。下图为通过ulimit将文件句柄数调整到10240后的情况。

随着文件句柄数的调整，客户端连接不再是问题，但如果客户端不规范或者一些错误的使用方式：比如客户端未设置心跳，网络异常时可能出现tcp半打开的情况，这将导致rabbitmq建立的连接不会释放；又或者是客户端错误的连接、异常重连逻辑，与rabbitmq建立了非常多的连接。当rabbitmq的连接数达到设置的上限时，将会导致rabbitmq无法正常工作。所以有必要更精确的限制客户端的连接数，避免客户端不正确的使用方式导致rabbitmq异常。

---

实际上，可以通过配置项connection_max来精确的限制客户端的连接数（这里仅针对默认的5672端口的连接数进行限制）。例如：

listeners.tcp.default=5672tcp_listen_options.nodelay=trueconnection_max=1000

测试过程中，发现实际的最大连接数比connection_max设置的值总要多几个。例如：connection_max设置为1000时，实际建立的连接数最多可达到1009个；设置为5000时，建立的连接数最多可以达到5009个。

分析了相关源码后，发现是配置项num_acceptors.tcp引起的。经典格式的配置文件中对应的配置项是num_tcp_acceptors。

该配置项对应的值表示accept的进程个数，每个accept进程接受新连接后，先完成连接的处理，然后再判断连接总数是否超过最大值，如果超过最大值，则阻塞不再accept。这样上面提到的现象就可以解释得通了。

注意：connection_max设置的值，内部判断是小于，而不是小于等于，也就是说真正的最大连接数计算方式为两个配置项的值相加再减1：

Count = connection_max +num_acceptors -1

通过相关命令可以进行确认验证：

分析相关源码过程中，还发现了另一个文档未公开，但可以进行配置的参数：file_handles_high_watermark。该配置项仅能在经典格式（".config"）的配置文件中进行配置，例如：

[{rabbit, [{file_handles_high_watermark,2000}]}].

设置后，可以直接从web管理界面或日志中看到其限制的值大小。

不过，该参数的实际效果与ulimit类似，几乎都是采用同样的方式计算最大文件句柄数与最大连接数（上图中日志文件中的信息可以看出来）。

 

欢迎扫码关注