web集群中经常使用的session同步解决方式及对照

随着站点的功能越来越多,用户量越来越庞大,单节点模式已经严重不能支撑整个系统的正常运作,轻则用户页面訪问时间越来越慢。重则就会导致整个系统瘫痪。这时候

就须要优化或调整眼下的架构,大部分人就会採用各种负载均衡软件比如nginx、hproxy、LVS等,也有的採用分布式的方式把系统依据功能拆分成非常多系统,也有的依据地域

和网络不同来实现訪问不同节点部署的系统。也有的大型高流量、高负载的系统把负载均衡、分布式及依据地域、网络等这些方式都整合在一起来实现系统的正常执行。

採用负载均衡软件是眼下大家採取的比較多的方式。可是在採用负载均衡软件时将会面临session同步的问题。

下面是解决这个问题的几种方式。

1. clientcookie加密的方式

把session数据存放在cookie中,当请求过来时。从cookie中获取session数据。这样的方式不须要不论什么的存储系统。也不会出现读写session数据带来的网络操作延时和不稳定性。

可是有下面缺点:

* Cookie有长度限制,这会影响session数据的长度。

* 安全性。

session数据本来存储在服务端的,而这个方法是让session数据转到外部网络或client中。所以会有安全性问题。只是能够对写入Cookie的session 数据做加密。

* 带宽消耗。因为加了session数据。带宽当然也会添加一点。

* 性能消耗。每次Http请求和响应都带有Session数据。对于Webserver来说,在相同的处理情况下,响应的结果输出越少,支持的并发请求越。

2. web server的session复制方式

大部分应用server都提供了session复制的功能来实现集群。tomcat、jboss、was都提供了这种功能。session复制就是每台应用服务。都保存会话session数据。

长处:

靠应用容器来完毕session共享,并不依赖应用。假设应用服务数量并非非常多,能够考虑。

缺点:

* 同步session数据带来都网络开销。

仅仅要session数据变化,就须要同步到全部机器上,机器越多,网络开销越大。

* 因为每台server都保存session数据,假设集群的session数据非常多。比方90万人在訪问站点。每台机器用于保存session数据的内容占用非常严重。

3. 使用关系数据库保存session     

用mysql、sqlserver等数据库保存session,就算服务器宕机了也没事,session照样在。

缺点:

*程序须要定制。

*每次请求都进行数据库读写开销不小(使用内存数据库能够提高性能,宕机就会丢失数据。

可供选择的内存数据库有BerkeleyDB,Mysql的内存表);

4.使用nosql数据库保存session

採用redis、mongodb、memcached等非关系数据库来实现session的共享。这些非关系数据库响应数据非常的快,并且支持的訪问量也比較大。系统资源消耗也比較少。这也是非常多系统所採用的方式。

可是也有缺点:

* 读写session引入了网络操作。相对于本机读写session,带来了延时和不稳定性。

* 如Session集中服务有问题,会影响应用。

5.採用Session Stick

在单机情况。session保存在单机上,请求也是到这台单机上,不会有问题。变成多台后,假设能保障每次请求都到同一台服务。那就和单机一样了。 这须要在负载均衡设备上改动。这就是Session Stick。这样的方式也会有问题:

* 假设某一台server宕机或重新启动。那么这台server上的session数据就丢失了。假设session数据中还有登录状态信息。那么用户须要重现登录。

* 负载均衡要处理详细的session到server的映射。

6.使用terracotta来保存session

跟memcached类似,可是数据不须要序列化。并且是Find-Grained Changes。性能更好。

配置对原来的应用全然透明,原有程序差点儿不用做不论什么改动。并且terracotta本身支持HA。

综上所述。我个人推荐使用第4、6种方式来解决session共享的问题。

时间: 2024-10-04 15:18:09

web集群中经常使用的session同步解决方式及对照的相关文章

关于WEB集群中文件服务器的讨论

原文地址: http://blog.itpub.net/29806344/viewspace-1364778/ 在WEB集群中一般都要上传和删除图片.小规模的时候,图片放在本地,再通过同步方式来保持一致. 常见的文件服务器:samba+web,ftp+web,nfs+web,rsync单向同步,分布式存储 samba+web,ftp+web这2种需要改程序代码,用的不多:rsync单向同步在小环境中用:nfs+web在中型环境用的最多:大型环境,海量文件用的是分布式存储,比如hadoop等. 一

web集群中常用的session同步解决方案及对比

随着网站的功能越来越多,用户量越来越庞大,单节点模式已经严重不能支撑整个系统的正常运作,轻则用户页面访问时间越来越慢,重则就会导致整个系统瘫痪.这时候 就需要优化或调整目前的架构,大部分人就会采用各种负载均衡软件例如nginx.hproxy.LVS等,也有的采用分布式的方式把系统根据功能拆分成很多系统,也有的根据地域 和网络不同来实现访问不同节点部署的系统,也有的大型高流量.高负载的系统把负载均衡.分布式及根据地域.网络等这些方式都整合在一起来实现系统的正常运行. 采用负载均衡软件是目前大家采取

Web集群实现共享存储的架构演变及MogileFS

本篇博客从Web集群中亟需解决的大容量存储问题引入,分析了几类常用的共享存储架构,重点解析了分布式存储系统的原理及配置实现: =================================================================== 1 共享存储的架构演变 2 分布式存储系统 2.1 基础知识 2.2 分类 2.3 CAP理论 2.4 协议 3 MogileFS 3.1 特性 3.2 架构 3.3 组成 3.4 服务安装及启动 3.5 配置部署 3.6 配置前端代理N

web集群环境中的session同步几种方法

在做了web集群后,你肯定会首先考虑session同步问题,因为通过负载均衡后,同一个IP访问同一个页面会被分配到不同的服务器上,如果 session不同步的话,一个登录用户,一会是登录状态,一会又不是登录状态.所以本文就根据这种情况给出三种不同的方法来解决这个问题: 一,利用数据库同步session 1,用一个低端电脑建个数据库专门存放web服务器的session,或者,把这个专门的数据库建在文件服务器上,用户访问web服务器时,会去这个专门的数据库check一下session的情况,以达到s

nginx负载均衡集群中的session共享说明

在网站使用nginx+php做负载均衡情况下,同一个IP访问同一个页面会被分配到不同的服务器上,如果session不同步的话,就会出现很多问题,比如说最常见的登录状态. 下面罗列几种nginx负载均衡中session同步的方式 1)不使用session,换用cookiesession是存放在服务器端的,cookie是存放在客户端的,我们可以把用户访问页面产生的session放到cookie里面,就是以cookie为中转站.你访问web服务器A,产生了session然后把它放到cookie里面,当

Memcached 在集群中的 session 共享存储

以下是 PHP Web 环境集群中的 session 共享存储设置: [[email protected] ~]# cat /etc/php.inisession.save_handler = memcache session.save_path = "tcp://192.168.5.131:11211" 配置完在 phpinfo 页面中查看:

如何在tomcat集群中实现Session共享

转自:http://www.toutiao.com/i6388049068718817794/ Apache集群实现Tomcat的Session共享配置其实很简单,在Tomcat自带的文档中有详细的说明( /docs/cluster-howto.html ),只不过是英语的,所以联合 下面根据说下怎么配置吧: 1.既然是集群肯定要多准备几个Tomcat来模拟,比如分别为Tomcat01.Tomcat02.Tomcat03. 如果各Tomcat程序放在不同的机器上,那么就不会有端口的冲突.如果是放

MSM实现tomcat集群中session共享的高可用

目录 1.测试环境概述 2.MSM简介 2.1.MSM的特性 2.2.MSM要解决的问题 2.3.MSM的工作原理 3.环境搭建 3.1.memcached安装 3.2.jkd与tomcat安装配置 3.3.MSM sticky session + kryo模式的配置 3.4.MSM no-sticky session + kryo模式的配置 4.思考与总结 1.测试环境概述 采用两台linux x64主机,主机上分别安装memcached与tomcat,memcached提供key/value

负载均衡集群中的session解决方案

前言 在我们给Web站点使用负载均衡之后,必须面临的一个重要问题就是Session的处理办法,无论是PHP.Python.Ruby还是Java,只要使用服务器保存Session,在做负载均衡时都需要考虑Session的问题. 分享目录: 问题在哪里?如何处理? 会话保持(案例:Nginx.Haproxy) 会话复制(案例:Tomcat) 会话共享(案例:Memcached.Redis) 问题在哪里? 从用户端来解释,就是当一个用户第一次访问被负载均衡代理到后端服务器A并登录后,服务器A上保留了用