使用haproxy进行会话保持
目录
现象说明
http出口的负载均衡策略是roundrobin，部分业务系统将会话信息保存在backend server，backend server之间未做同步。
用户在访问、操作的时候，会出现会话不连贯的现象 。
方案说明
haproxy可以使用多种方式做到会话保持，可以在balance中指定均衡算法：
balance <algorithm> [ <arguments> ]
balance url_param <param> [check_post]
source的方式将同一个源IP的请求转发给同一个backend server，可以作用于tcp和http。但是当某个源IP的请求量较大，或者用户请求经过NAT后到达，会导致backend server的负载严重不均衡。不采用。
url_param的方式，需要业务在url中带有sessionid，适用于http。不采用。
也可以使用stick-tables的方式。stick-table设置复杂，且需要维护记录表。不采用。
还可以使用cookie的方式。cookie本身也有多种策略，例如insert，prefix，rewrite等，适用于http。
经过对比，决定采用以下方式：
cookie cookie.XXXXX.cn insert indirect postonly
即：
只有遇到post请求的时候，haproxy在响应中设置一个名为
`cookie.XXXXX.cn`的cookie，后续带有该cookie的请求到达
haproxy时，haproxy将该cookie去除后，转发给cookie指定的backen server。
过程说明
未发送post请求之前，依然采用roundrobin的方式
第一次get请求：
第二次get请求:
发送了post请求后，被设置cookie
cookie的值为处理post请求的backend server的ID。
后续请求被转发到同一个backend server
用户后续所有http请求，都会带上cookie，被转发到同一个backend server。
绑定的backend server宕机后，cookie失效
绑定的backend server宕机后，虽然后续发送的请求中依然会带有cookie，但是这时候会重新回到roundrobin的状态，直到用户再次发送POST请求，重新绑定backend server。
宕机后，再次发送POST的情形：
参考
