大型网站系统架构实践（五）深入探讨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

此时产生的sessionId为jvm3

2. 停掉webA，刷新浏览器

可以看到请求被转发到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 。

架构图：

该方案解决了haproxy单点故障的问题，具体用keepalived实现，详细请参考文章：

Keepalived 实现双机热备

Keepalived + haproxy双机高可用方案

如果想实践的朋友，请按照上面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

应用访问地址

http://192.168.1.99/login/

注意sessionId的后缀为jvm3

查看虚拟ip1.99对应的mac地址

接下来，我们停掉master上的haproxy服务

kill -9 9644

查看haproxy http://192.168.1.99/haproxy-stats

发现haproxy的pid变成backup机器上的了

刷新web的访问页面http://192.168.1.99/login/

发现sessionId没有变化

查看虚拟ip1.99对应的mac地址

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层负载均衡之haproxy实践篇（一）

目录 大型网站系统架构的演进目录

下篇 大型网站系统架构实践（六）深入探讨web应用集群Session保持