web集群中常用的session同步解决方案及对比
2015-12-07 22:17
471 查看
随着网站的功能越来越多,用户量越来越庞大,单节点模式已经严重不能支撑整个系统的正常运作,轻则用户页面访问时间越来越慢,重则就会导致整个系统瘫痪。这时候
就需要优化或调整目前的架构,大部分人就会采用各种负载均衡软件例如nginx、hproxy、LVS等,也有的采用分布式的方式把系统根据功能拆分成很多系统,也有的根据地域
和网络不同来实现访问不同节点部署的系统,也有的大型高流量、高负载的系统把负载均衡、分布式及根据地域、网络等这些方式都整合在一起来实现系统的正常运行。
采用负载均衡软件是目前大家采取的比较多的方式。但是在采用负载均衡软件时将会面临session同步的问题。以下是解决问题的几种方式。
1. 客户端cookie加密的方式
把session数据存放在cookie中,当请求过来时,从cookie中获取session数据。这种方式不需要任何的存储系统,也不会出现读写session数据带来的网络操作延时和不稳定性。
但是有以下缺点:
* Cookie有长度限制,这会影响session数据的长度。
* 安全性。session数据本来存储在服务端的,而这个方案是让session数据转到外部网络或客户端中,所以会有安全性问题。不过可以对写入Cookie的session 数据做加密。
* 带宽消耗。由于加了session数据,带宽当然也会增加一点。
* 性能消耗。每次Http请求和响应都带有Session数据,对于Web服务器来说,在同样的处理情况下,响应的结果输出越少,支持的并发请求越。
2. web server的session复制方式
大部分应用服务器都提供了session复制的功能来实现集群,tomcat、jboss、was都提供了这样的功能。session复制就是每台应用服务,都保存会话session数据。
优点:
靠应用容器来完成session共享,并不依赖应用,如果应用服务数量并不是很多,可以考虑;
缺点:
* 同步session数据带来都网络开销。只要session数据变化,就需要同步到所有机器上,机器越多,网络开销越大。
* 由于每台服务器都保存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,这种方式也会有问题:
* 如果某一台服务器宕机或重启,那么这台服务器上的session数据就丢失了。如果session数据中还有登录状态信息,那么用户需要重现登录。
* 负载均衡要处理具体的session到服务器的映射。
6.使用terracotta来保存session
跟memcached类似,但是数据不需要序列化,并且是Find-Grained Changes,性能更好。配置对原来的应用完全透明,原有程序几乎不用做任何修改。而且terracotta本身支持HA。
综上所述,我个人推荐使用第4、6种方式来解决session共享的问题。
就需要优化或调整目前的架构,大部分人就会采用各种负载均衡软件例如nginx、hproxy、LVS等,也有的采用分布式的方式把系统根据功能拆分成很多系统,也有的根据地域
和网络不同来实现访问不同节点部署的系统,也有的大型高流量、高负载的系统把负载均衡、分布式及根据地域、网络等这些方式都整合在一起来实现系统的正常运行。
采用负载均衡软件是目前大家采取的比较多的方式。但是在采用负载均衡软件时将会面临session同步的问题。以下是解决问题的几种方式。
1. 客户端cookie加密的方式
把session数据存放在cookie中,当请求过来时,从cookie中获取session数据。这种方式不需要任何的存储系统,也不会出现读写session数据带来的网络操作延时和不稳定性。
但是有以下缺点:
* Cookie有长度限制,这会影响session数据的长度。
* 安全性。session数据本来存储在服务端的,而这个方案是让session数据转到外部网络或客户端中,所以会有安全性问题。不过可以对写入Cookie的session 数据做加密。
* 带宽消耗。由于加了session数据,带宽当然也会增加一点。
* 性能消耗。每次Http请求和响应都带有Session数据,对于Web服务器来说,在同样的处理情况下,响应的结果输出越少,支持的并发请求越。
2. web server的session复制方式
大部分应用服务器都提供了session复制的功能来实现集群,tomcat、jboss、was都提供了这样的功能。session复制就是每台应用服务,都保存会话session数据。
优点:
靠应用容器来完成session共享,并不依赖应用,如果应用服务数量并不是很多,可以考虑;
缺点:
* 同步session数据带来都网络开销。只要session数据变化,就需要同步到所有机器上,机器越多,网络开销越大。
* 由于每台服务器都保存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,这种方式也会有问题:
* 如果某一台服务器宕机或重启,那么这台服务器上的session数据就丢失了。如果session数据中还有登录状态信息,那么用户需要重现登录。
* 负载均衡要处理具体的session到服务器的映射。
6.使用terracotta来保存session
跟memcached类似,但是数据不需要序列化,并且是Find-Grained Changes,性能更好。配置对原来的应用完全透明,原有程序几乎不用做任何修改。而且terracotta本身支持HA。
综上所述,我个人推荐使用第4、6种方式来解决session共享的问题。
相关文章推荐
- python核心编程-递归(阶乘)
- HDU 1059 Dividing(多重背包二进制优化)
- 图片的圆角处理
- dbcp数据库连接超时解决方案
- Java设计模式之简单工厂模式
- 杨小麦OC之旅--多线程
- 内嵌汇编
- 提升网页性能
- LAMP 1.8默认虚拟主机
- 实验四实验报告
- Java虚拟机 程序计数器
- 黑马程序员——OC之self关键字、多态
- Linux第五次实验
- python核心编程-作用域
- 美团O2O排序解决方案——线下篇
- LeetCode 009 Palindrome Number
- which命令
- Linux第五次实验
- 美团推荐算法实践:机器学习重排序模型成亮点
- java web 过滤器跟拦截器的区别和使用