NGINX发布的1.9.1版本引入了一个新的特性：允许使用SO_REUSEPORT套接字选项，该选项在许多操作系统的新版本中是可用的，包括DragonFly BSD和Linux(内核版本3.9及以后)。该套接字选项允许多个套接字监听同一IP和端口的组合。内核能够在这些套接字中对传入的连接进行负载均衡。

　　(对于NGINX Plus客户，此功能将在年底发布的版本7中出现)

　　SO_REUSEPORT选项有许多潜在的实际应用。其他服务也可以使用它来简单实现执行中的滚动升级(Nginx已经通过不同的办法支持了滚动升级)。对于NGINX而言，启用该选项可以减少在某些场景下的锁竞争而改善性能。

　　如下图描述，当SO_REUSEPORT选项有效时，一个单独的监听socket通知工作进程接入的连接，并且每个工作线程都试图获得连接（http://www.nanke0834.com）。

　　当SO_REUSEPORT选项启用是，存在对每一个IP地址和端口绑定连接的多个socket监听器，每一个工作进程都可以分配一个。系统内核决定哪一个有效的socket监听器(通过隐式的方式，给哪一个工作进程)获得连接。这可以减少工作进程之间获得新连接时的封锁竞争(译者注：工作进程请求获得互斥资源加锁之间的竞争)，同时在多核系统可以提高性能。然而，这也意味着当一个工作进程陷入阻塞操作时，阻塞影响的不仅是已经接受连接的工作进程，也同时让内核发送连接请求计划分配的工作进程因此变为阻塞。

　　设置共享Socket

　　为了让SO_REUSEPORT socket选项起作用，应为HTTP或TCP(流模式)通信选项内的listen项直接引入新近的reuseport参数，就像下例这样：

　　复制代码 代码如下:

　　http {

　　server { listen 80 reuseport;

　　server_name localhost;

　　...

　　}

　　}

　　stream {

　　server { listen 12345 reuseport;

　　...

　　}

　　}

　　引用reuseport参数后，对引用的socket，accept_mutex参数将会无效，因为互斥量(mutex)对reuseport来说是多余的。对没有使用reuseport的端口，设置accept_mutex仍然是有价值的。

　　reuseport的基准性能测试

　　我在一个36核的AWS实例运行wrk基准测试工具测试4个NGINX 工作进程.为了减少网络的影响，客户端和NGINX都运行在本地，并且让NGINX返回OK字符串而不是一个文件。我比较三种NGINX配置：默认(等同于accept_mutex on ),accept_mutex off,和reuseport。如图所示，reuseport的每秒请求是其余的两到三倍，同时延迟和延迟标准差也是减少的。

　　我又运行了另一个相关的性能测试——客户端和NGINX分别在不同的机器上且NGINX返回一个HTML文件。如下表所示，用 reuseport 减少的延迟和之前的性能测试相似，延迟的标准差减少的更为显著(接近十分之一)。其他结果(没有显示在表格中)同样令人振奋。使用 reuseport ，负载被均匀分离到了worker进程。在默认条件下(等同于 accept_mutex on)，一些worker分到了较高百分比的负载，而用 accept_mutex off 所有worker都受到了较高的负载。