基于Nginx的软件负载均衡实现解读

(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了。
(2)Sticky Routes　
也是在backend第一次response之后，会产生一个route信息，route信息通常会从cookie/URI信息中提取。
这样Nginx会按照顺序搜索routecookie、route_uri参数并选择第一个非空的参数用作route，而如果所有的参数都是空的，就使用上面默认的负载均衡算法决定请求分发给哪个backend。