大型网站之分布式会话管理

转载 2015年11月18日 18:40:57

大型网站之分布式会话管理

随着网站的功能和用户越来越多,单机器服务部署的Web应用已经不能再支持了。这时候就需要优化或调整目前的架构,具体怎么优化,或先优化哪部分,这取决于网站的具体情况, 并非总是一个套路。

如根据使用情况得知,数据库压力大,则就可以先设施读写分离,分库分表,是垂直划分(可以简单的理解为按业务功能划分), 还是水平划分(如用户表数据量很多,就可以按一定的规则分表设计,表结构仍然是相同的)。如Web应用服务器压力大,可以增加一台服务部署应用, 即从单台服务变为集群。变为集群后,用户访问网站,到底是选择哪一台服务器呢?这就需要在应用服务器前增加负载均衡设备来解决。还有点就是会话session 管理的问题,接下来会详细说明这问题。

具体的问题

当一个带有会话表示的Http请求到Web服务器后,需求在请求中的处理过程中找到session数据。而问题就在于,session是保存在单机上的。 假设我们有应用A和应用B,现在一位用户第一次访问网站,session数据保存在应用A中。如果我们不做处理,怎么保障接下来的请求每次都请求到应用A呢? 如请求到了应用B中,就会发现没有这位用户的session数据,这绝对是不能容忍的。

解决方案

解决方案有Session Stick,Session复制,Session集中管理,基于Cookie管理,下面一一说明。

Session Stick

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

如果某一台服务器宕机或重启,那么这台服务器上的session数据就丢失了。如果session数据中还有登录状态信息,那么用户需要重现登录。
负载均衡要处理具体的session到服务器的映射。

Session复制

Session复制顾名思义,就是每台应用服务,都保存会话session数据,一般的应用容器都支持。与Session Stick相比,sessioon复制对负载均衡 没有太多的要求。不过这个方案还是有缺点:

同步session数据带来都网络开销。只要session数据变化,就需要同步到所有机器上,机器越多,网络开销越大。
由于每台服务器都保存session数据,如果集群的session数据很多,比如90万人在访问网站,每台机器用于保存session数据的内容占用很严重。

这就是Session复制,这个方案是靠应用容器来完成,并不依赖应用,如果应用服务数量并不是很多,可以考虑。

Session集中管理

这个也很好理解,再加一台服务,专门来管理session数据,每台应用服务都从专门的session管理服务中取会话session数据。可以使用数据库,NOSQL数据库等。 和Session复制相比,减少了每台应用服务的内存使用,同步session带来的网络开销问题。但还是有缺点:

读写session引入了网络操作,相对于本机读写session,带来了延时和不稳定性。
如Session集中服务有问题,会影响应用。

基于Cookie管理

最后一个是基于Cookie管理,我们把session数据存放在cookie中,然后请求过来后,从cookie中获取session数据。与集中管理相比,这个方案并不依赖外部 的存储系统,读写session数据带来的网络操作延时和不稳定性。但依然有缺点:

Cookie有长度限制,这会影响session数据的长度。
安全性。session数据本来存储在服务端的,而这个方案是让session数据转到外部网络或客户端中,所以会有安全性问题。不过可以对写入Cookie的session 数据做加密。
带宽消耗。由于加了session数据,带宽当然也会增加一点。
性能消耗。每次Http请求和响应都带有Session数据,对于Web服务器来说,在同样的处理情况下,响应的结果输出越少,支持的并发请求越多。

总结

这4种方案都是可用的方案,我比较倾向于使用Session集中管理,不过这4种方案都各有优劣,需要根据具体的实际场景做出合适的选择。

大型网站之分布式会话管理

大型网站之分布式会话管理  Published: 01 Oct 2015  Category: design 随着网站的功能和用户越来越多,单机器服务部署的Web应用已经不能再支持了。...
  • Lotes
  • Lotes
  • 2015年10月07日 14:56
  • 210

java中的分布式应用(二)之各类中间件中用到的算法

为了便于区分分布式系统中用到的各类中间件所使用的算法,这里记录了他们的核心算法,但由于个人能力有限,不涉及算法实现,有关算法实现请大家另寻他路,这里只记录中间件核心算法以及简单介绍: 缓存系统之me...
  • zzjstudent
  • zzjstudent
  • 2016年08月30日 10:13
  • 2464

TensorFlow(二)之分布式

本博文参考TensorFlow技术解析与实战(李嘉璇),仅用于学习。 一、原理 分布式TensorFlow是由高性能的gRPC库作为底层技术来支持的。gRPC是Google开源的RPC框架(远程过...
  • chenglong_123
  • chenglong_123
  • 2018年01月15日 09:31
  • 16

clickhouse之分布式(distribute)

Distribute    原文地址:https://clickhouse.yandex/docs/en/table_engines/distributed.html   clickhouse...
  • u013676711
  • u013676711
  • 2017年12月24日 14:22
  • 279

Jmeter之分布式测试

由于 (1)Jmeter 是纯java 应用,对于CPU和内存的消耗比较大,并且受到JVM的一些限制;    一般情况下,依据机器配置,单机的发压量为300~600,因此,当需要模拟数以千...
  • qq_28940479
  • qq_28940479
  • 2017年10月27日 15:20
  • 47

JMeter之分布式部署

Jmeter运行的时候十分耗内存和cpu,本人机子跑到500多个进程的时候,就卡死了。所以,有必要说利用多部机子进行分布式测试。 在进行分布式平台测试的时候,你先要检查一下以下的内容: 1 所有的...
  • ww3614358
  • ww3614358
  • 2016年08月09日 11:55
  • 175

大型网站架构之分布式消息队列

大型网站架构之分布式消息队列   以下是消息队列以下的大纲,本文主要介绍消息队列概述,消息队列应用场景和消息中间件示例(电商,日志系统)。 本次分享大纲 消息队列概述消息队列应用场景消息中...
  • shaobingj126
  • shaobingj126
  • 2016年01月26日 08:48
  • 122622

高并发之分布式

分布式的好处1、成倍提高系统承载能力并降低成本单机遇到资源瓶颈时,要想支持更大的用户量,一般是优化业务和增加服务器配置。然而这么做只能是杯水车薪,成本巨大并且效果非常有限。采用分布式部署,你可以利用多...
  • Floatdellab
  • Floatdellab
  • 2017年07月15日 22:57
  • 11143

架构之分布式消息队列

一、消息队列概述  消息队列中间件是分布式系统中重要的组件,主要解决应用耦合,异步消息,流量削锋等问题。实现高性能,高可用,可伸缩和最终一致性架构。是大型分布式系统不可缺少的中间件   目前在生产环...
  • u014354066
  • u014354066
  • 2016年03月11日 10:25
  • 170

计算机英语之分布式数据库系统

分散式系统在数据库领域中称为分布式系统,这种系统能处理不同的数据采集、存储和访问方一式。它可以根据用户的心理,例如可针对个性强的希腊雇员和守纪律的日本雇员之间的差异作出调整,它也可适应不同地方的各种管...
  • u014648838
  • u014648838
  • 2014年04月11日 09:07
  • 157
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:大型网站之分布式会话管理
举报原因:
原因补充:

(最多只允许输入30个字)