目录
3.2.3使用后端服务器自身通过相关机制保持session同步
一、Nginx优点
Nginx 是一个很强大的高性能Web和反向代理服务，它具有很多非常优越的特性：
在连接高并发的情况下，Nginx是Apache服务不错的替代品：Nginx在美国是做虚拟主机生意的老板们经常选择的软件平台之一。能够支持高达 50,000 个并发连接数的响应，感谢Nginx为大家选择了 epoll and kqueue作为开发模型。
二、Nginx配置项——Conf
Upstream 模块
upstream 这个模块是写一组被代理的服务器地址（即定义的后端服务器列表中选取一台服务器接受用户的请求 ），然后配置负载均衡的算法。
upstream web_test {
server 10.10.2.100:80;
server 10.10.3.100:80;
}
server {
....
location / {
proxy_pass http://web_test; --请求转向 web_test 定义的服务器列表
} 三、Nginx负载均衡
- rr 负载均衡模式： 每个请求按时间顺序逐一分配到不同的后端服务器，如果超过了最大失败次数后（max_fails，默认1），在失效时间内(fail_timeout，默认10秒)，该节点失效权重变为0，超过失效时间后，则恢复正常，或者全部节点都为down后，那么将所有节点都恢复为有效继续探测，一般来说rr可以根据权重来进行均匀分配。
- least_conn 最少连接： 优先将客户端请求调度到当前连接最少的服务器。
- ip_hash 负载均衡模式： 每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题，但是ip_hash会造成负载不均，有的服务请求接受多，有的服务请求接受少，所以不建议采用ip_hash模式，session 共享问题可用后端服务的 session 共享代替 nginx 的 ip_hash（使用后端服务器自身通过相关机制保持session同步）。
- fair（第三方）负载均衡模式： 按后端服务器的响应时间来分配请求，响应时间短的优先分配。
- url_hash（第三方）负载均衡模式： 基于用户请求的uri做hash。和ip_hash算法类似，是对每个请求按url的hash结果分配，使每个URL定向到同一个后端服务器，但是也会造成分配不均的问题，这种模式后端服务器为缓存时比较好。
1.负载均衡策略
1.1轮询
最基本的配置方法，上面的例子就是轮询的方式，它是upstream模块默认的负载均衡默认策略。每个请求会按时间顺序逐一分配到不同的后端服务器。
upstream web_test {
server 10.10.2.100:80;
server 10.10.3.100:80;
}1.2IP_hash
每个请求按访问IP的hash结果分配，同一个IP客户端固定访问一个后端服务器。可以保证来自同一ip的请求被打到固定的机器上，可以解决session问题。
upstream web_test {
ip_hash; --同一个IP客户端固定访问一个后端服务器
server 10.10.2.100:80;
server 10.10.3.100:80;
}1.3URL_hash
按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器。一旦缓存住了资源，再次收到请求，就可以从缓存中读取。
upstream web_test {
hash $request_uri; --实现每个url定向到同一个后端服务器
server 10.10.2.100:80;
server 10.10.3.100:80;
}1.4Least_conn
把请求转发给连接数较少的后端服务器。轮询算法是把请求平均的转发给各个后端，使它们的负载大致相同；但是，有些请求占用的时间很长，会导致其所在的后端负载较高。这种情况下，least_conn这种方式就可以达到更好的负载均衡效果。
upstream web_test {
least_conn; --把请求转发给连接数较少的后端服务器
server 10.10.2.100:80;
server 10.10.3.100:80;
}1.5Weight
权重方式，在轮询策略的基础上指定轮询的比例。
一般来说，性能好的服务器权重大，性能差的权重给小一些。
upstream web_test {
server 10.10.2.100:80; weight=1;
server 10.10.3.100:80; weight=2; --轮询的比例相对上一条要大
}1.6Fair
此种算法可以依据页面大小和加载时间长短智能地进行负载均衡，也就是根据后端服务器的响应时间来分配请求，响应时间短的优先分配。
upstream web_test {
server 10.10.2.100:80;
server 10.10.3.100:80;
fair; --实现响应时间短的优先分配
}2.Nginx负载均衡配置状态参数
- down：表示当前的server暂时不参与负载均衡。
- backup：预留的备份机器。当其他所有的非backup机器出现故障或者忙的时候，才会请求backup机器，因此这台机器的压力最轻。
- max_fails：允许请求失败的次数，默认为1。当超过最大次数时，返回proxy_next_upstream 模块定义的错误。
- fail_timeout：在经历了max_fails次失败后，暂停服务的时间单位秒。max_fails可以和fail_timeout一起使用。
3.什么是会话保持
我们在访问网站的时候，进行登录以后，服务器上会生成一个session，然后服务器会携带着session_id返回给浏览器记录一个cookie值，当第二次访问时，cookie会来服务器上与session进行对比，如果对比成功，则不需要重新登录
3.1会话保持有什么作用呢
简单说就是优化用户体验，降低网络开销
如果有一个用户访问请求被分配到服务器A，并且在服务器A登录了，并且在很短的时间，这个用户又发出了一个请求，如果没有会话保持功能的话，这个用户的请求很有可能会被分配到服务器B去，这个时候在服务器B上是没有登录的，所以你要重新登录，但是用户并不知道自己的请求被分配到了哪里，用户的感觉就是登录了，怎么又要登录，用户体验很不好。
还有你在淘宝上面买东西，从登录-->拍得东西-->添加地址-->付款，这是一个一系列的过程，也可以理解成一次操作过程，所有这一系列的操作过程都应当由一台服务器完成，而不能被负载均衡器分配到不同的服务器上。
会话保持都会有时间的限制（映射到固定某一台的服务器除外，如：ip_hash）,各种负载均衡工具都会提供这种会话保持时间的设置，LVS，apache等。连php语言都提供了会话保持时间的设定session.gc_maxlifetime会话保持时间的设定要大于session生存时间的设定，这样可以减少需要同步session的情况，但是不能杜绝。所以同步session还是要做的。
3.2Nginx会话保持
3.2.1IP_hash
ip_hash使用源地址哈希算法，将同一客户端的请求总是发往同一个后端服务器，除非该服务器不可用。
upstream backend {
ip_hash;
server backend1.example.com;
server backend2.example.com;
server backend3.example.com down;
server backend4.example.com;
}ip_hash简单易用，但有如下问题：
当后端服务器宕机后，session会丢失；
来自同一局域网的客户端会被转发到同一个后端服务器，可能导致负载失衡；
不适用于CDN网络，不适用于前端还有代理的情况。
3.2.2sticky_cookie_insert
使用sticky_cookie_insert启用会话亲缘关系，这会导致来自同一客户端的请求被传递到一组服务器在同一台服务器。与ip_hash不同之处在于，它不是基于IP来判断客户端的，而是基于cookie来判断。因此可以避免上述ip_hash中来自同一局域网的客户端和前端代理导致负载失衡的情况。
upstream backend {
server backend1.example.com;
server backend2.example.com;
sticky_cookie_insert srv_id expires=1h domain=3evip.cn path=/;
}expires：设置浏览器中保持cookie的时间
domain：定义cookie的域
path：为cookie定义路径
3.2.3使用后端服务器自身通过相关机制保持session同步
使用数据库、redis、memcached等做session复制
104
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
