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

原理

       在第三，四篇文章中讲到了会话保持的问题，而且还遗留了一个问题，就是会话保持存在单点故障，

当时的方案是cookie插入后缀，即haproxy指负责分发请求，应用服务自行保持用户会话，如果应

用服务器宕机，则session会丢失。

现在来温习下解决方案

方案1：session复制

原理	就是将1台服务器的session复制到其它所有的服务器上，这样无论访问哪台服务器，都会得到用户 的session
优点	不存在单点故障问题
缺点	当服务器的数量比较大时，session同步将会变得相当耗时

 方案2：session粘滞

原理	就是用户请求一个服务器之后，同一个会话的其它请求，都会被分配到这台服务器，session粘滞的 功能由负载均衡中间件完成
优点	解决了session复制的性能问题
缺点	由于用户的会话被保存到单一的服务器，就容易出现单点故障

      

 

 

 

 

方案3：session服务器

原理	部署一个专门的服务，保存用户session，同时在web服务器本地也保存一份，当本地没有或者失效时， 去访问session服务器，当然session服务器就成了单点，当用户量大的时候也容易宕机，这时可以做一 个session服务器集群，做主备同步备份，这样就达到了较好的效果，具体实现可以用redies，memcached 等缓存中间件。
优点	解决了单点故障和性能问题
缺点	实现复杂

      

 

 

 

       

      

 

redis保存session方案

      上篇文章讲到的就是session粘滞的方案，既然前2种方案都有各自的缺点，那么就采用第三中方案     

可以用redis做session缓存，保存用户session，做成主备模式，采用同步备份或者异步备份。

同步备份：在主机宕机时，备机接管之后session数据不丢失。

异步备份：在主机宕机时，备机接管主机，但是如果有一部分session还没来得及同步到备机，session将丢失。

可以根据实际情况来决定采用同步备份还是异步备份。

系统架构图如下：

如果用户量比较大，单服务器访问和存储session将会成为瓶颈，可以考虑用session服务器集群，架构图如下：

redis集群特点

1）将数据分散到集群中的多个节点，每个节点存储的数据量就会变少，这样存储和访问

的效率会得到提升。

2）每个节点都有主备，如果节点的主存储挂了，备份存储会接管主存储，提高可用性。

Redis+Tomcat实现

session流程

1.客户端首次请求服务端

2.服务端产生session并set cookie响应给客户端

3.客户端再次请求服务端，会带上cookie

4.服务端根据cookie找到对应的session

实现思路

如果我们要编写程序实现这个方案，需要解决以下问题：

1.session的安全性，即不容易被仿造。

2.session的唯一性，如果用tomcat产生session的策略，多台tomcat会产生的session会存在重复的可能。

3.session的有效期维护，session会有个有效期，用户在这个时间内不访问系统，session将会失效，如果

用户一直访问，则要自动延长session有效期。

4.在集群session服务器中，要考虑负载均衡，这也是需要编写客户端代码的，在分布式session缓存中，

需要根据sessionId哈希分布，那么就和服务器个数进行了耦合，在添加和移除服务器的时候，将出现数

据不一致的问题 。

5.如何实现才能让应用程序改动最小，或者是不改动。

我们可以选择自己写程序来实现以上功能，不过在这里我使用一个现成的框架，即tomcat-redis-session-manager

有时间并感兴趣的朋友，可以在这个基础上自行实现一个，这样更适合自己的项目。

服务器部署分布：

ha主机 192.168.1.227:80

ha备机 192.168.1.246:80

keepalived 主机 192.168.1.227

keepalived备机 192.168.1.246

web1 http://192.168.1.226:8888/login

web2 http://192.168.1.246:8888/login

redis主 192.168.1.245 6380

redis备

安装redis

主机和备机都安装redis

wget http://download.redis.io/releases/redis-2.8.5.tar.gz

解压：

tar xzf redis-2.8.5.tar.gz

cd redis-2.8.5

make

启动

src/redis-server redis.conf --port 6380 &

客户端登录

src/redis-cli -p 6380

备机配置复制：

redis.conf文件中

添加

slaveof 192.168.1.245 6380

Tomcat配置

tomcat版本：7.0.61

相关jar包：

注意这里的jar包最好是按下面的版本，否则会出现jar包冲突的问题。

tomcat-redis-session-manager-1.1.jar

commons-pool-1.6.jar

jedis-2.1.0.jar

下载tomcat redis session manager

https://github.com/jcoleman/tomcat-redis-session-manager/downloads

下载 apache common pool

http://commons.apache.org/proper/commons-pool/download_pool.cgi

下载版本：tomcat-redis-session-manager-1.1

redis的jar包可以从maven中央仓库下载

将以上3个jar包放入tomcat/lib目录中

在tomcat context.xml中加入如下内容

<!-- host: optional: defaults to "localhost" -->
<!-- port: defaults to "6379" -->
<!-- database: optional: defaults to "0" -->
<!-- maxInactiveInterval: optional: defaults to "60" (in seconds) -->
<Valve className="com.radiadesign.catalina.session.RedisSessionHandlerValve" />
<Manager className="com.radiadesign.catalina.session.RedisSessionManager"
    host="192.168.1.245" port="6380" database="0" maxInactiveInterval="60" />

启动tomcat，浏览器请求tomcat

http://192.168.1.226:8888/login/

 

登录redis客户端，查看session

session已经被保存到redis

下面，我们进行一项测试

测试流程：

1.先访问虚拟ip1.99的应用，得到sessionId

web服务器是226

2.然后将对应的tomcat停掉

3.刷新该应用，若sessionId未变，则表示redis保存session成功。

我们发现web服务器变成了246，但是sessionId未发生变化

该方案将session集中保存在了redis服务器，并做了主备容灾，从一定程度上提高了系统的高可用，由于

redis是内存存储，访问效率较高，在性能上也是比较好的，但是本例中session不是分布式存储，因此当用户量

非常大，并发访问量非常高的时候，session服务器会成为性能瓶颈。

 

上篇 大型网站系统架构实践（五）深入探讨web应用高可用方案

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