2.1网站的高可用架构之高可用应用

应用层主要处理业务逻辑，显著的一个特点是应用的无状态性，所谓无状态性指的是应用服务器不保存业务上下文信息，仅仅根据每次提交的请求进行相应的业务逻辑处理，多个服务器实例之间完全对等，请求提交到任何一个服务器，处理结果都是完全一样的。应用服务器的无状态性也有利于网站的伸缩性，可以方便的往集群中添加服务器，通过负载均衡机制，来缓解其余服务器压力。

1、利用负载均衡进行无状态服务的失效转移

利用负载均衡机制，在网站业务量和数据量较高的情况下，将请求分摊到集群中的服务器，以提高整体的负载处理能力。负载均衡服务器通过心跳检测机制发现到宕机的服务器时，将其从服务器列表中剔除，将请求发送到其他服务器上，由于应用服务器是对等的，因此处理结果都一样。

2、应用服务器集群的session管理

应用服务器设计为无状态的，有利于高可用。但是，类似于电子购物以及社交类应用，业务总是有状态的，服务器需要知道当前处理的是哪个用户的请求。Web应用中将多次请求的上下文对象称为session，单机情况下可以将session直接由部署在服务器上的web容器管理，如Tomcat、Jboss等。但是在集群环境下，由于负载均衡机制会将用户请求分发到集群中其他服务器上，所以需要保证每次请求能够获取到正确的session。集群环境下，session管理的手段主要有以下几种。

2.1 session复制

应用服务器开启web容器的session复制功能，在集群的几台服务器之间同步session对象，使得所有的集群服务器之间都保存有同样的session信息。该方案简单，从本机读取session信息迅速，适用于集群中服务器数量少的情况下，但是当集群规模较大时，集群服务器之间需要进行大量的通信来进行session复制，会消耗大量的服务器和网络资源。大型网站不适合这种方案。

2.2 Session绑定

利用负载均衡的源地址Hash算法，session绑定将来自于同一IP地址的请求（或者是根据cookie信息将同一个用户的请求）总是分发到同一台服务器，保证session总能在这一台服务器上获取。但是这并不符合高可用的设计需求，因为若该服务器宕机，那么其上的session也就不在了，其他服务器上也没有保存该服务器上的session信息。该方案应用也较少。

2.3 利用Cookie记录session

利用Cookie记录session有一些弊端，如Cookie大小受限制，能传输的信息有限；每次请求都要传输Cookie，影响性能；若用户关闭Cookie，就会影响使用。优点：Cookie简单易用，支持服务器的线性伸缩，而且大部分session需要记录的信息也小，因此许多网站或多或少都会使用cookie记录session。

2.4 session服务器

利用统一部署的session服务器集群来管理session，应用服务每次读写session时，从session服务器读取。这种解决方案将无状态的应用服务器和有状态的session服务器分离，针对这两种不同的特性在分别设计其架构。对于有状态的session服务器，简单的方法时利用分布式缓存、数据库等。若业务场景要求较高，需要开发专门的session服务管理平台。