（点击上方公众号，可快速关注）
来源：taozj
链接：taozj.org/201612/nginx-load-balancing.html
负载均衡在服务端开发中算是一个比较重要的特性。因为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\ | 
注册
登录
