Nginx 负载均衡实现解读

负载均衡在服务端开发中算是一个比较重要的特性。因为Nginx除了作为常规的Web服务器外,还会被大规模的用于反向代理前端,因为Nginx的异步框架可以处理很大的并发请求,把这些并发请求hold住之后就可以分发给后台服务端(backend servers,也叫做服务池, 后面简称backend)来做复杂的计算、处理和响应,这种模式的好处是相当多的:隐藏业务主机更安全,节约了公网IP地址,并且在业务量增加的时候可以方便地扩容后台服务器。

负载均衡可以分为硬件负载均衡和软件负载均衡,前者一般是专用的软件和硬件相结合的设备,设备商会提供完整成熟的解决方案,通常也会更加昂贵。软件的复杂均衡以Nginx占据绝大多数,本文也是基于其手册做相应的学习研究的。

一、基本简介

负载均衡涉及到以下的基础知识。

(1) 负载均衡算法

  a. Round Robin: 对所有的backend轮训发送请求,算是最简单的方式了,也是默认的分配方式;

  b. Least Connections(least_conn): 跟踪和backend当前的活跃连接数目,最少的连接数目说明这个backend负载最轻,将请求分配给他,这种方式会考虑到配置中给每个upstream分配的weight权重信息;

  c. Least Time(least_time): 请求会分配给响应最快和活跃连接数最少的backend;

  d. IP Hash(ip_hash): 对请求来源IP地址计算hash值,IPv4会考虑前3个octet,IPv6会考虑所有的地址位,然后根据得到的hash值通过某种映射分配到backend;

  e. Generic Hash(hash): 以用户自定义资源(比如URL)的方式计算hash值完成分配,其可选consistent关键字支持一致性hash特性;

(2) 会话一致性

用户(浏览器)在和服务端交互的时候,通常会在本地保存一些信息,而整个过程叫做一个会话(Session)并用唯一的Session ID进行标识。会话的概念不仅用于购物车这种常见情况,因为HTTP协议是无状态的,所以任何需要逻辑上下文的情形都必须使用会话机制,此外HTTP客户端也会额外缓存一些数据在本地,这样就可以减少请求提高性能了。如果负载均衡可能将这个会话的请求分配到不同的后台服务端上,这肯定是不合适的,必须通过多个backend共享这些数据,效率肯定会很低下,最简单的情况是保证会话一致性——相同的会话每次请求都会被分配到同一个backend上去。

(3) 后台服务端的动态配置

出问题的backend要能被及时探测并剔除出分配群,而当业务增长的时候可以灵活的添加backend数目。此外当前风靡的Elastic Compute云计算服务,服务商也应当根据当前负载自动添加和减少backend主机。

(4) 基于DNS的负载均衡

通常现代的网络服务者一个域名会关连到多个主机,在进行DNS查询的时候,默认情况下DNS服务器会以round-robin形式以不同的顺序返回IP地址列表,因此天然将客户请求分配到不同的主机上去。不过这种方式含有固有的缺陷:DNS不会检查主机和IP地址的可访问性,所以分配给客户端的IP不确保是可用的(Google 404);DNS的解析结果会在客户端、多个中间DNS服务器不断的缓存,所以backend的分配不会那么的理想。

二、Nginx中的负载均衡

Nginx中的负载均衡配置在手册中描述的极为细致,此处就不流水帐了。对于常用的HTTP负载均衡,主要先定义一个upstream作为backend group,然后通过proxy_pass/fastcgi_pass等方式进行转发操作,其中fastcgi_pass几乎算是Nginx+PHP站点的标配了。

2.1 会话一致性

Nginx中的会话一致性是通过sticky开启的,会话一致性和之前的负载均衡算法之间并不冲突,只是需要在第一次分配之后,该会话的所有请求都分配到那个相同的backend上面。目前支持三种模式的会话一致性:

(1). Cookie Insertion

在backend第一次response之后,会在其头部添加一个session cookie,即由负载均衡器向客户端植入 cookie,之后客户端接下来的请求都会带有这个cookie值,Nginx可以根据这个cookie判断需要转发给哪个backend了。

sticky cookie srv_id expires=1h domain=.example.com path=/;

上面的srv_id代表了cookie的名字,而后面的参数expires、domain、path都是可选的。

(2). Sticky Routes

也是在backend第一次response之后,会产生一个route信息,route信息通常会从cookie/URI信息中提取。

sticky route $route_cookie $route_uri;

这样Nginx会按照顺序搜索routecookie、route_uri参数并选择第一个非空的参数用作route,而如果所有的参数都是空的,就使用上面默认的负载均衡算法决定请求分发给哪个backend。

(3). Learn

较为的复杂也较为的智能,Nginx会自动监测request和response中的session信息,而且通常需要回话一致性的请求、应答中都会带有session信息,这和第一种方式相比是不用增加cookie,而是动态学习已有的session。

这种方式需要使用到zone结构,在Nginx中zone都是共享内存,可以在多个worker process中共享数据用的。(不过其他的会话一致性怎么没用到共享内存区域呢?)

sticky learn create=$upstream_cookie_examplecookie lookup=$cookie_examplecookie zone=client_sessions:1m timeout=1h;

2.2 Session Draining

主要是有需要关闭某些backend以便维护或者升级,这些关键性的服务都讲求gracefully处理的:就是新的请求不会发送到这个backend上面,而之前分配到这个backend的会话的后续请求还会继续发送给他,直到这个会话最终完成。

让某个backend进入draining的状态,既可以直接修改配置文件,然后按照之前的方式通过向master process发送信号重新加载配置,也可以采用Nginx的on-the-fly配置方式。

$ curl http://localhost/upstream_conf?upstream=backend $ curl http://localhost/upstream_conf?upstream=backend\&id=1\&drain=1

通过上面的方式,先列出各个bacnkend的ID号,然后drain指定ID的backend。通过在线观测backend的所有session都完成后,该backend就可以下线了。

2.3 backend健康监测

backend出错会涉及到两个参数,max_fails=1 fail_timeout=10s;意味着只要Nginx向backend发送一个请求失败或者没有收到一个响应,就认为该backend在接下来的10s是不可用的状态。

通过周期性地向backend发送特殊的请求,并期盼收到特殊的响应,可以用以确认backend是健康可用的状态。通过health_check可以做出这个配置。

match server_ok { status 200-399; header Content-Type = text/html; body !~ "maintenance mode"; } server { location / { proxy_pass http://backend; health_check interval=10 fails=3 passes=2 match=server_ok; } }

上面的health_check是必须的,后面的参数都是可选的。尤其是后面的match参数,可以自定义服务器健康的条件,包括返回状态码、头部信息、返回body等,这些条件是&&与关系。默认情况下Nginx会相隔interval的间隔向backend group发送一个”/“的请求,如果超时或者返回非2xx/3xx的响应码,则认为对应的backend是unhealthy的,那么Nginx会停止向其发送request直到下次改backend再次通过检查。

在使用了health_check功能的时候,一般都需要在backend group开辟一个zone,在共享backend group配置的同时,所有backend的状态就可以在所有的worker process所共享了,否则每个worker process独立保存自己的状态检查计数和结果,两种情况会有很大的差异哦。

2.4 通过DNS设置HTTP负载均衡

Nginx的backend group中的主机可以配置成域名的形式,如果在域名的后面添加resolve参数,那么Nginx会周期性的解析这个域名,当域名解析的结果发生变化的时候会自动生效而不用重启。

http { resolver 10.0.0.1 valid=300s ipv6=off; resolver_timeout 10s; server { location / { proxy_pass http://backend; } } upstream backend { zone backend 32k; least_conn; ... server backend1.example.com resolve; server backend2.example.com resolve; } }

如果域名解析的结果含有多个IP地址,这些IP地址都会保存到配置文件中去,并且这些IP都参与到自动负载均衡。

2.5 TCP/UDP流量的负载均衡

通常,HTTP和HTTPS的负载均衡叫做七层负载均衡,而TCP和UDP协议的负载均衡叫做四层负载均衡。因为七层负载均衡通常都是HTTP和HTTPS协议,所以这种负载均衡相当于是四层负载均衡的特例化,均衡器可以根据HTTP/HTTPS协议的头部(User-Agent、Language等)、响应码甚至是响应内容做额外的规则,达到特定条件特定目的的backend转发的需求。

除了Nginx所专长的HTTP负载均衡,Nginx还支持TCP和UDP流量的负载均衡,适用于LDAP/MySQL/RTMP和DNS/syslog/RADIUS各种应用场景。这类情况的负载均衡使用stream来配置,Nginx编译的时候需要支持–with-stream选项。查看手册,其配置原理和参数和HTTP负载均衡差不多。

因为TCP、UDP的负载均衡都是针对通用程序的,所以之前HTTP协议支持的match条件(status、header、body)是没法使用的。TCP和UDP的程序可以根据特定的程序,采用send、expect的方式来进行动态健康检测。

match http { send "GET / HTTP/1.0\r\nHost: localhost\r\n\r\n"; expect ~* "200 OK"; }

2.6 其他特性

slow_start=30s:防止新添加/恢复的主机被突然增加的请求所压垮,通过这个参数可以让该主机的weight从0开始慢慢增加到设定值,让其负载有一个缓慢增加的过程。

max_conns=30:可以设置backend的最大连接数目,当超过这个数目的时候会被放到queue队列中,同时队列的大小和超时参数也可以设置,当队列中的请求数大于设定值,或者超过了timeout但是backend还不能处理请求,则客户端将会收到一个错误返回。通常来说这还是一个比较重要的参数,因为Nginx作为反向代理的时候,通常就是用于抗住并发量的,如果给backend过多的并发请求,很可能会占用后端过多的资源(比如线程、进程非事件驱动),最终反而会影响backend的处理能力。

原文发布于微信公众号 - nginx(nginx-study)

原文发表时间:2018-05-26

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏北京马哥教育

【图文并茂】一步步带你了解Web站点架构

1.1 http反向代理服务器 在web站点前端,我们需要搭建一个反向代理服务器,用于负责接受用户的请求,请求包括动态和静态的内容请求。一般反向代理服务器的部署...

51780
来自专栏枕边书

linux的“自动化”

linux的“自动化” linux系统的web网站在运营状态时,我们常需要对网站进行维护,例如查看资源剩余并做出响应、日志分割、数据整理,在特定状态执行特定任务...

25790
来自专栏北京马哥教育

20个命令行工具监控 Linux 系统性能

对于每个系统管理员或网络管理员来说,每天要监控和调试 Linux 系统性能问题都是非常困难的工作。我已经有5年 Linux 管理员的工作经历,知道如何监控系统使...

44990
来自专栏全栈

Maven管理多模块应用

27310
来自专栏微服务生态

缓存穿透、缓存并发、缓存失效之思路变迁

我们在用缓存的时候,不管是Redis或者Memcached,基本上会通用遇到以下三个问题:

15840
来自专栏分享达人秀

开发IDE大升级,终于迎来了Android Studio

通过前面几期的学习,我们知道了Android的前世今生,也了解了Android的系统架构和应用组件,也连续用了几期来学习Android开发环境的搭建,不...

275100
来自专栏杨建荣的学习笔记

Oracle Data Guard压缩归档效果对比(r12笔记第26天)

Oracle Data Guard对归档的传输提供了很多辅助的选项,这个可 以通过log_archive_dest_x看到。 一般说这类的优化,如果...

38070
来自专栏c#开发者

在 BizTalk Server 2004 SP2 中存档和清除 BizTalk 跟踪数据库

在 Biztalk Server 2004 SP2 中存档和清除 Biztalk 跟踪数据库 发布日期: 2006年09月19日 小结:本白皮书介绍如何配置 B...

36930
来自专栏about云

kafka权威指南 第二章第6节 Kafka集群配置与调优

问题导读: 1 Kafka集群有什么优势? 2 集群中部署多少个节点合适? 3 集群针对系统如何调优? Kafka集群 对于本地的开发工作或者概念性的...

41260
来自专栏freesan44

ACP互联网架构认证笔记-EDAS企业级分布式应用服务

EDAS支持语言Java,C++,PHP。EDAS支持Idea,Eclipse;Eclipse插件安装等编译工具。EDAS初级版仅支持应用的部署管理,不支持HS...

48570

扫码关注云+社区

领取腾讯云代金券