Nginx基于TCP/UDP端口的四层负载均衡（Stream模块）配置梳理

Nginx基于TCP/UDP端口的四层负载均衡（Stream模块）配置梳理

在关系数据库中，索引是一种单独的、物理的对数据库表中一列或多列的值进行排序的一种存储结构，它是某个表中一列或若干列值的集合和相应的指向表中物理标识这些值的数据页的逻辑指针清单。

作者：波波说运维来源：今日头条|2019-09-12 14:47

HTTP负载均衡，也就是我们通常所有"七层负载均衡"，工作在第七层"应用层"。而TCP负载均衡，就是我们通常所说的"四层负载均衡"，工作在"网络层"和"传输层"。例如，LVS(Linux Virtual Server，Linux虚拟服务)和F5(一种硬件负载均衡设备)，也是属于"四层负载均衡"

1. nginx-1.9.0 已发布，该版本增加了stream 模块用于一般的TCP 代理和负载均衡，ngx_stream_core_module 这个模块在1.90版本后将被启用。但是并不会默认安装， 
2. 需要在编译时通过指定 --with-stream 参数来激活这个模块。 
3. 1）配置Nginx编译文件参数 
4. ./configure --with-http_stub_status_module --with-stream 
5. ------------------------------------------------------------------ 
6. 2）编译、安装，make && make install 
7. ------------------------------------------------------------------ 
8. 3）配置nginx.conf文件 
9. stream { 
10.  upstream kevin { 
11.  server 192.168.10.10:8080; #这里配置成要访问的地址 
12.  server 192.168.10.20:8081; 
13.  server 192.168.10.30:8081; #需要代理的端口，在这里我代理一一个kevin模块的接口8081 
14.  server { 
15.  listen 8081; #需要监听的端口 
16.  proxy_timeout 20s; 
17.  proxy_pass kevin; 
18. 创建最高级别的stream（与http同一级别），定义一个upstream组 名称为kevin，由多个服务组成达到负载均衡 定义一个服务用来监听TCP连接（如：8081端口）， 
19. 并且把他们代理到一个upstream组的kevin中，配置负载均衡的方法和参数为每个server；配置些如：连接数、权重等等。 
20. 首先创建一个server组，用来作为TCP负载均衡组。定义一个upstream块在stream上下文中，在这个块里面添加由server命令定义的server，指定他的IP地址和 
21. 主机名（能够被解析成多地址的主机名)和端口号。下面的例子是建立一个被称之为kevin组，两个监听1395端口的server ，一个监听8080端口的server。 
22. upstream kevin { 
23.  server 192.168.10.10:8080; #这里配置成要访问的地址 
24.  server 192.168.10.20:8081; 
25.  server 192.168.10.30:8081; #需要代理的端口，在这里我代理一一个kevin模块的接口8081 
26. 需要特别注意的是： 
27. 你不能为每个server定义协议，因为这个stream命令建立TCP作为整个 server的协议了。 
28. 配置反向代理使Nginx能够把TCP请求从一个客户端转发到负载均衡组中(如：kevin组)。在每个server配置块中 通过每个虚拟server的server的配置信息和在 
29. 每个server中定义的监听端口（客户端需求的代理端口号，如我推流的的是kevin协议，则端口号为：8081）的配置信息和proxy_passs 命令把TCP通信发送到 
30. upstream的哪个server中去。下面我们将TCP通信发送到kevin 组中去。 
31.  server { 
32.  listen 8081; #需要监听的端口 
33.  proxy_timeout 20s; 
34.  proxy_pass kevin; 
35. 当然我们也可以采用单一的代理方式： 
36. server { 
37.  listen 8081; #需要监听的端口 
38.  proxy_timeout 20s; 
39.  proxy_pass 192.168.10.30:8081; #需要代理的端口，在这里我代理一一个kevin模块的接口8081 
40. ------------------------------------------------------------------ 
41. 4）改变负载均衡的方法： 
42. 默认nginx是通过轮询算法来进行负载均衡的通信的。引导这个请求循环的到配置在upstream组中server端口上去。 因为他是默认的方法，这里没有轮询命令， 
43. 只是简单的创建一个upstream配置组在这儿stream山下文中，而且在其中添加server。 
44. a）least-connected ：对于每个请求，nginx plus选择当前连接数最少的server来处理: 
45. 　upstream kevin { 
46. least_conn; 
47.  server 192.168.10.10:8080; #这里配置成要访问的地址 
48.  server 192.168.10.20:8081; 
49.  server 192.168.10.30:8081; #需要代理的端口，在这里我代理一一个kevin模块的接口8081 
50. b）least time ：对于每个链接,nginx pluns 通过几点来选择server的： 最底平均延时：通过包含在least_time命令中指定的参数计算出来的： 
51. connect：连接到一个server所花的时间 
52. first_byte：接收到第一个字节的时间 
53. last_byte：全部接收完了的时间 最少活跃的连接数: 
54. 　upstream kevin { 
55. least_time first_byte; 
56.  server 192.168.10.10:8080; #这里配置成要访问的地址 
57.  server 192.168.10.20:8081; 
58.  server 192.168.10.30:8081; #需要代理的端口，在这里我代理一一个kevin模块的接口8081 
59. c）普通的hash算法：nginx plus选择这个server是通过user_defined 关键字，就是IP地址：$remote_addr; 
60. upstream kevin { 
61. hash $remote_addr consistent; 
62.  server 192.168.10.10:8080 weight=5; #这里配置成要访问的地址 
63.  server 192.168.10.20:8081 max_fails=2 fail_timeout=30s; 
64.  server 192.168.10.30:8081 max_conns=3; #需要代理的端口，在这里我代理一一个kevin模块的接口8081 

Nginx的TCP负载均衡的执行原理

当Nginx从监听端口收到一个新的客户端链接时，立刻执行路由调度算法，获得指定需要连接的服务IP，然后创建一个新的上游连接，连接到指定服务器。

TCP负载均衡支持Nginx原有的调度算法，包括Round Robin(默认，轮询调度)，哈希(选择一致)等。同时，调度信息数据也会和健壮性检测模块一起协作，为每个连接选择适当的目标上游服务器。如果使用Hash负载均衡的调度方法，你可以使用$remote_addr(客户端IP)来达成简单持久化会话(同一个客户端IP的连接，总是落到同一个服务server上)。

和其他upstream模块一样，TCP的stream模块也支持自定义负载均和的转发权重(配置“weight=2”)，还有backup和down的参数，用于踢掉失效的上游服务器。max_conns参数可以限制一台服务器的TCP连接数量，根据服务器的容量来设置恰当的配置数值，尤其在高并发的场景下，可以达到过载保护的目的。

Nginx监控客户端连接和上游连接，一旦接收到数据，则Nginx会立刻读取并且推送到上游连接，不会做TCP连接内的数据检测。Nginx维护一份内存缓冲区，用于客户端和上游数据的写入。如果客户端或者服务端传输了量很大的数据，缓冲区会适当增加内存的大小。

当Nginx收到任意一方的关闭连接通知，或者TCP连接被闲置超过了proxy_timeout配置的时间，连接将会被关闭。对于TCP长连接，我们更应该选择适当的proxy_timeout的时间，同时，关注监听socke的so_keepalive参数，防止过早地断开连接。

Nginx的TCP负载均衡服务健壮性监控

TCP负载均衡模块支持内置健壮性检测，一台上游服务器如果拒绝TCP连接超过proxy_connect_timeout配置的时间，将会被认为已经失效。在这种情况下，Nginx立刻尝试连接upstream组内的另一台正常的服务器。连接失败信息将会记录到Nginx的错误日志中。

如果一台服务器，反复失败(超过了max_fails或者fail_timeout配置的参数)，Nginx也会踢掉这台服务器。服务器被踢掉60秒后，Nginx会偶尔尝试重连它，检测它是否恢复正常。如果服务器恢复正常，Nginx将它加回到upstream组内，缓慢加大连接请求的比例。

之所"缓慢加大"，因为通常一个服务都有"热点数据"，也就是说，80%以上甚至更多的请求，实际都会被阻挡在"热点数据缓存"中，真正执行处理的请求只有很少的一部分。在机器刚刚启动的时候，"热点数据缓存"实际上还没有建立，这个时候爆发性地转发大量请求过来，很可能导致机器无法"承受"而再次挂掉。以mysql为例子，我们的mysql查询，通常95%以上都是落在了内存cache中，真正执行查询的并不多。

其实，无论是单台机器或者一个集群，在高并发请求场景下，重启或者切换，都存在这个风险，解决的途径主要是两种：

1)请求逐步增加，从少到多，逐步积累热点数据，最终达到正常服务状态。

2)提前准备好"常用"的数据，主动对服务做"预热"，预热完成之后，再开放服务器的访问。

TCP负载均衡原理上和LVS等是一致的，工作在更为底层，性能会高于原来HTTP负载均衡不少。但是，不会比LVS更为出色，LVS被置于内核模块，而Nginx工作在用户态，而且，Nginx相对比较重。另外一点，令人感到非常可惜，这个模块竟然是个付费功能。

【编辑推荐】

点赞 0

大家都在看猜你喜欢