大型网站系统架构实践(六)深入探讨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应用高可用方案

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

时间: 2024-10-27 06:29:08

大型网站系统架构实践(六)深入探讨web应用集群Session保持的相关文章

高并发高负载的大型网站系统架构(转)

高并发高负载的大型网站系统架构(转) 一个小型的网站,比如个人网站,可以使用最简单的html静态页面就实现了,配合一些图片达到美化效果,所有的页面均存放在一个目录下,这样的网站对系统架构.性能的要求都很简单,随着互联网业务的不断丰富,网站相关的技术经过这些年的发展,已经细分到很细的方方面面,尤其对于大型网站来说,所采用的技术更是涉及面非常广,从硬件到软件.编程语言.数据库.WebServer.防火墙等各个领域都有了很高的要求,已经不是原来简单的html静态网站所能比拟的. 大型网站,比如门户网站

高并发高负载的大型网站系统架构

大型网站的系统架构需要考虑很多问题.大型网站有高并发高负载的特点,在面对大量用户访问.高并发请求方面,基本的解决方案集中在这样几个环节:使用高性能的服务器.高性能的数据库.高效率的编程语言.还有高性能的Web容器.本文从低成本.高性能和高扩张性的角度来探讨了一些大型网站系统架构需要考虑的问题. AD:WOT2014:用户标签系统与用户数据化运营培训专场 一个小型的网站,比如个人网站,可以使用最简单的html静态页面就实现了,配合一些图片达到美化效果,所有的页面均存放在一个目录下,这样的网站对系统

大型网站系统架构技术原理透析

跟朋友聊天的时候,发现很多人对大型网站系统架构非常感兴趣,我也很感兴趣,经常会在家里2台笔记本和1台服务器组成的局域网环境里作些实验.我进 入IT行业的时间,大约是97,98年吧,那时候PC客户端软件最为盛行,做软件开发是一份很体面也很喜欢的工作.我从Win3.1上的VC1.5开始一 直到VC6.0,然后转为.Net开发,基本上都是从事客户端软件开发.本人的性格是危机意识向来严重,所以深感互联网必将盛行,传统软件必将走向没落, 于是转向了WEB开发.记得以前去某Portal网站应聘的时候,主考官

大型网站系统架构的演进(四)http层负载均衡之haproxy实践篇(一)

方案 上篇文章讲到了负载均衡的相关理论知识,这篇文章我打算讲讲实践方法以及实践中遇到的问题 方案:haproxy http层负载均衡 安装一个haproxy服务,两个web服务 haproxy:192.168.1.227:80 web1 http://192.168.1.226:8081/login web2 http://192.168.1.246:8888/login web服务自行准备,文章中就不说了 负载均衡算法为轮询调度 会话保持实现方式为cookie识别,插入cookie 优点: 1

大型网站系统架构

大型网站系统架构 dubbo+ssh+nginx负载均衡/动静分离+数据库主从+缓存+分布式存储+队列 1.缓存--利用缓存改善网站性能a.缓存包含本地缓存和分布式缓存:本地缓存如OSCache,分布式缓存如Memcached.Redis. b.本地缓存和分布式缓存的特点本地缓存的特点是速度快,但是本地空间有限所以缓存数据量也有限.分布式缓存的特点是,可以缓存海量的数据,并且扩展非常容易,响应速度没有本地缓存快. 2.服务器集群--使用服务器集群改善应用服务器性能应用服务器作为网站的入口,会承担

大型网站系统架构演化和关键技术普及课程

大型网站系统架构演化和关键技术普及 课程观看地址:http://www.xuetuwuyou.com/course/40 课程出自学途无忧网:http://www.xuetuwuyou.com/ 了解大型网站的架构是如何一步步进行演变和改进的,并对其中的一些关键技术知识做普及. 课时1:原始架构的诞生 课时2:缓存的介绍 课时3:集群&负载均衡 课时4:数据库分库分表演变 课时5:CDN&反向代理等技术手段 课时6:分布式服务&空节点等技术手段

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

大型网站系统架构的演进(一) 大型网站系统架构的演进(二)分布式模块之间的通信 大型网站系统架构的演进(三)如何提高网站的高可用和高性能

谈谈运行稳定性好效率高的千万级大型网站系统架构性分析

千万级的注册用户,千万级的帖子,nTB级的附件,还有巨大的日访问量,大型网站采用什么系统架构保证性能和稳定性? 首先讨论一下大型网站需要注意和考虑的问题. 数据库海量数据处理:负载量不大的情况下select.delete和update是响应很迅速的,最多加几个索引就可以搞定,但千万级的注册用户和一个设计不好的多对多关系将带来非常严重的性能问题.另外在高UPDATE的情况下,更新一个聚焦索引的时间基本上是不可忍受的.索引和更新是一对天生的冤家. 高并发死锁:平时我们感觉不到,但数据库死锁在高并发的

大型网站系统架构的演化(转)

前言 一个成熟的大型网站(如淘宝.京东等)的系统架构并不是开始设计就具备完整的高性能.高可用.安全等特性,它总是随着用户量的增加,业务功能的扩展逐渐演变完善的,在这个过程中,开发模式.技术架构.设计思想也发生了很大的变化,就连技术人员也从几个人发展到一个部门甚至一条产品线.所以成熟的系统架构是随业务扩展而完善出来的,并不是一蹴而就:不同业务特征的系统,会有各自的侧重点,例如淘宝,要解决海量的商品信息的搜索.下单.支付,例如腾讯,要解决数亿的用户实时消息传输,百度它要处理海量的搜索请求,他们都有各