大型网站系统架构实践（五）深入探讨web应用高可用方案
从上篇文章到这篇文章，中间用了一段时间准备，主要是想把东西讲透，同时希望大家给与一些批评和建议，这样我才能有所进步，也希望喜欢我文章的朋友，给个赞，这样我才能更有激情，呵呵。
由于本篇要写的内容有点多，我就分为几篇博客进行了详细描述。
Haproxy提高web应用的高可用
上一篇文章讲到了haproxy+tomcat的方案，文章地址：大型网站系统架构的演进（四）http层负载均衡之haproxy实践篇（一）
大家可以先温习一下，
文中提到了高可用，该集群方案也可以提高应用系统的高可用，如果tomcat应用出现故障，或者tomcat应用服务器出现故障，haproxy会检测到（这里指的是定期心跳检查），并将应用从可用列表中删除，打开监控页面http://192.168.1.227/haproxy-stats
可以看到有2个web应用运行，如果将webA停掉，可以看到webA显示down
这样客户端请求就不会分发给webA，下面模拟一下webA宕机的情况
这里对sessionId增加了一个后缀做标记
webA：jvm3
webB：jvm2
1. webA正常的情况，客户请求被分发到webA
![clip_image005[3]](http://images0.cnblogs.com/blog/722277/201504/160948092603009.png "clip_image005[3]")
此时产生的sessionId为jvm3
2. 停掉webA，刷新浏览器
![clip_image006[3]](http://images0.cnblogs.com/blog/722277/201504/160948105103294.png "clip_image006[3]")
可以看到请求被转发到webB
也就是说web应用出现故障，haproxy会做切换，因此可以保证web应用的高可用。
Haproxy本身的高可用
如果haproxy本身出现故障，那么网站将不可用，所以我们接下来要做的事情就是解决haproxy单点故障的问题。
我们可以运用虚拟ip技术，将haproxy部署在2台服务器上，一台做为master，正常运营，一台为backup，
当master出现问题的时候，接管master。
首先有一个虚拟ip暴露给客户端，虚拟ip对应的mac地址为master服务器，
用户向虚拟ip发送一个请求，该请求会被分发到master服务器上，当master出现故障时，被backup检测到，则backup成为master,
且发送消息将arp缓存虚拟ip对应的mac地址backup的mac地址，这样发送到虚拟ip的报文会被转发到backup 。
架构图：
![clip_image007[3]](http://images0.cnblogs.com/blog/722277/201504/160948121204237.png "clip_image007[3]")
该方案解决了haproxy单点故障的问题，具体用keepalived实现，详细请参考文章：
如果想实践的朋友，请按照上面2篇文章安装和配置haproxy和keepalived
系统分布如下：
ha主机 192.168.1.227:80
ha备机 192.168.1.246
keepalived 主机 192.168.1.227
keepalived备机 192.168.1.246
web1 http://192.168.1.226:8081/login
web2 http://192.168.1.246:8888/login
虚拟ip 192.168.1.99
安装好haproxy和keepalived后，启动haproxy和keepalived
Haproxy访问地址：
http://192.168.1.99/haproxy-stats
注意pid为9644，这是master上的haproxy
应用访问地址
![clip_image010[3]](http://images0.cnblogs.com/blog/722277/201504/160948200421117.png "clip_image010[3]")
注意sessionId的后缀为jvm3
查看虚拟ip1.99对应的mac地址
![clip_image011[3]](http://images0.cnblogs.com/blog/722277/201504/160948216982344.png "clip_image011[3]")
接下来，我们停掉master上的haproxy服务
![clip_image012[3]](http://images0.cnblogs.com/blog/722277/201504/160948229016642.png "clip_image012[3]")
kill -9 9644
查看haproxy http://192.168.1.99/haproxy-stats
![clip_image013[1]](http://images0.cnblogs.com/blog/722277/201504/160948245895328.png "clip_image013[1]")
发现haproxy的pid变成backup机器上的了
刷新web的访问页面http://192.168.1.99/login/
![clip_image014[1]](http://images0.cnblogs.com/blog/722277/201504/160948261515583.png "clip_image014[1]")
发现sessionId没有变化
查看虚拟ip1.99对应的mac地址
![clip_image015[1]](http://images0.cnblogs.com/blog/722277/201504/160948275268596.png "clip_image015[1]")
mac地址已经变为backup机器上的了
如果我们直接关闭主机服务器或者关闭主机的keepalived，发现测试结果也是一样的
因此该方案实现了haproxy的高可用，解决了haproxy的单点故障问题。
会话保持问题
那么这里我还要提出一个疑问，为什么sessionId也没有变化呢？
也就是说切换到backup服务器的haproxy之后，
可以保持用户的会话，那么它是怎么实现的呢？
这里就要回到上篇文章讲的负载均衡时保持会话的策略
会话保持的流程
1.客户端首次请求，经过haproxy到web服务端时，web服务端set-cookie并响应到haproxy
2.haproxy在cookie后插入SRV=A，并响应客户端
3.客户端第二次请求，经过haproxy时，haproxy将srv后缀去掉，然后请求服务端
这种保持会话的方法是无状态的，也就说主要haproxy配置的负载均衡策略相同，不管在哪台机器上运行
将得到同样的结果
出处：http://www.cnblogs.com/tangyanbo/
本文以学习、研究和分享为主，欢迎转载，但必须在文章页面明显位置给出原文连接。 如果文中有不妥或者错误的地方还望高手的你指出，以免误人子弟。如果觉得本文对你有所帮助不如【推荐】一下！如果你有更好的建议，不如留言一起讨论，共同进步！ 再次感谢您耐心的读完本篇文章。欢迎加QQ讨论群
