1.nginx的会话保持
主要是用ip_hash这个均衡策略，根据来源ip进行hash，同一个ip进入同一个后端服务器，配置文件如下:
1 2 3 4 5 6
| upstream myapp1 { ip_hash; server srv1.example.com; server srv2.example.com; server srv3.example.com; }
|
官网在http://nginx.org/en/docs/http/ngx_http_upstream_module.html#ip_hash
官方虽然给了一个sticky的例子，但是那个只能在专业版里面才能用了。
2.tengine的会话保持
除了nginx的ip_hash模块以外还支持ngx_http_upstream_session_sticky_module模块，通过cookie实现客户端与后端服务器的会话保持, 在一定条件下可以保证同一个客户端访问的都是同一个后端服务器。
http://tengine.taobao.org/document_cn/http_upstream_session_sticky_cn.html
用法也是很简单:
1 2 3 4 5 6 7 8 9 10 11
| upstream foo { server 192.168.0.1; server 192.168.0.2; session_sticky; } server { location / { proxy_pass http://foo; } }
|
默认配置：cookie=route mode=insert fallback=on
添加一个cookie的值是route+后端服务器的md5的hash。
访问tengine会返回客户端一个Set-Cookie字段
1
| route=ace32a114586cbe7b88cc20323d8f180;Path=/
|
3.haproxy
支持的方法比较多。
3.1 类似nginx的ip_hash
3.2 cookie
cookie SRV insert indirect nocache
1 2 3 4 5 6 7 8 9
| frontend ft_web bind 0.0.0.0:4004 default_backend bk_web backend bk_web cookie SRV insert indirect nocache server s1 127.0.0.1:4001 check cookie s1 server s2 127.0.0.1:4002 check cookie s2
|
类似tengine的做法。也是加一个cookie。
4.会话保持的作用
很大的作用是为了让客户端的请求落到之前访问的后端服务器上. 当然架构设计可以避开这一点,直接用session集中放置,比如说放到redis或者memcached 里面去的方法来避开这一点.
用cookie插入方案时候要注意到cookie是存在client端的,最好加密,如果client不允许写cookie那么这种方案就悲剧了.
而且这种方案是针对session单独放置的解决方案,如果后端某台机器挂了,而且如果session里面存了登录信息,那么客户就要重新登录了.
还有这些操作都是基于7层协议,开销会比4层大.