nginx,tengine,haproxy会话保持

1.nginx的会话保持

主要是用ip_hash这个均衡策略，根据来源ip进行hash，同一个ip进入同一个后端服务器，配置文件如下:

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

用法也是很简单:

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字段

route=ace32a114586cbe7b88cc20323d8f180;Path=/

3.haproxy

支持的方法比较多。

3.1 类似nginx的ip_hash

balance source

3.2 cookie

cookie SRV insert indirect nocache

frontend ft_web    bind 0.0.0.0:4004    default_backend bk_webbackend 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层大.