我们公司一个系统大量使用session,请问这样会有什么后果影响?

10-05-25 dcz1001
我们公司的一个系统大量使用了Session,如:操作的业务中查询出来的数据集合都会放入session中,好在在点一个新菜单的时候清理一下session,请问这样系统性能会受什么程度的影响?

2
icycrystal4
2010-05-25 17:28
在单机(JVM)环境下性能不会受影响, 如果你的业务访问量比较大, 需要集群环境/分布式时, session复制会导致网络风暴, 也就是说依赖session会使得应用un-scalable

可以考虑SNA-share nothing architecture. (业务)机器与(业务)机器之间应该是相互独立的, 平等的, 彼此不应该通信, 不共享信息.

banq
2010-05-26 08:20
2010年05月25日 16:35 "dcz1001"的内容
系统性能会受什么程度的影响 ...

注意性能和可伸缩性的概念区别:
什么是性能问题?如果你的系统对于一个用户访问还很慢,那就是性能问题;
什么是可伸缩性问题?如果你的系统对一个用户来说是快的,但是在高访问量下就慢了。

所以,你这样做的问题不会带来单机性能问题,会带来可伸缩性问题,就是楼上un-scalable,会使得一个客户端总是粘住一个服务器方法,无法真正实现负载平衡。尽管你硬件用L5或用apache做平衡器。

shangtang004
2010-05-27 11:08
能不能具体点。或给个测试方法
集群环境/分布式下为什么就不行了

banq
2010-05-27 11:31
其实是因为Session + 状态是不可伸缩的。

详细点是这样:如果你在Session中保存一个与该客户端有关的状态,比如状态数值为1,下次该客户端再发一个请求时,需要到自己的Session中寻找这个数值为1的状态。

在分布式环境中有两种办法:
1.如果下次该客户端发出的请求不是访问的是上次请求的服务器,那么他在新服务器中就找不到数值为1的状态,因为被负载平衡器随机分配到新服务器上了。

2.为了让他找到数值1的状态,那么就在这两台服务器之间拷贝Session中的状态,数值1的状态从原来服务器拷贝到新服务器,第二次请求就能在新服务器上找到这个数值为1的状态。但来这样做的问题是:服务器就会耗费负载来处理服务器之间的拷贝,根本没有全心全意处理客户端发出的请求,严重发生风暴堵塞。



sunson468
2010-05-28 22:02
弄个session分配服务器,具体的逻辑再由各自服务器管理就行了,只要保证session不要分布就没关系了,至于你所说的性能,3个人的应用也有性能,3000个人也有性能,30000000也有性能,全世界都同时访问的那也有性能~
跟大量使用session的关系不算太大的,不过不太建议使用session管理业务数据,毕竟上述的技术还是需要做一些处理的~session是保存在服务器上的,大量臃肿的session会导致内存膨胀的厉害~所以session一般只有来保存必须保存的key信息

janwen
2010-05-31 09:38
2010年05月26日 08:20 "banq"的内容
注意性能和可伸缩性的概念区别:
什么是性能问题?如果你的系统对于一个用户访问还很慢,那就是性能问题;
什么是可伸缩性问题?如果你的系统对一个用户来说是快的,但是在高访问量下就慢了。

所以,你这样做的问题不会带来单机性能问题,会带来可伸缩性 ...

能不能针对非分布式的应用,讲讲关于session的应用,管理方面的话题呢,session的管理在非分布式应用中真的很头疼

banq
2010-05-31 17:25
2010年05月31日 09:38 "janwen"的内容
能不能针对非分布式的应用,讲讲关于session的应用 ...


从解耦设计角度考虑,Session一般能尽量不用就不用,要从对象的生命周期 状态管理周期这个角度认识Session和Cache,Session其实也是一种缓存,不过不是应用全局级别,而是随着某个客户端开始和离去有关,象你这个案例,完全可以用全局性的Cache来实现。

现在都是RIA富客户端和RESTful架构,其精神目的就是将和客户有关的状态缓存迁移到客户端,使用JS或AJAX来实现,通过这些措施,可以减少Session的使用。

如果你在Session中放一些可幂等方法的结果,也就是这个方法能够反复运行,这也是可以的,在分布式环境就不必同步Session,因为可以即时生成,作为特殊缓存使用。

总之:忘记Session,不倚重Session,复杂的界面渲染不要依赖服务器端Session,而是迁移到客户端,这样才能真正利用http无状态特性,Session实际就是因为http无状态,而强加给服务器的一个状态容器,这不符合自然之道,不符合巧妙之道,是简单问题复杂化,必然会被遗弃。

jackhatedance
2010-06-11 07:19
大多数程序都没利用好session,基本就存放一个购物车或者登陆用户id,或者其他全局性的变量。
所以,传统mvc程序都把session荒废了。
因为session存放容易,清除却找不到良好时机。
你们把点一个菜单作为清除的时机还算不错了,说明这些状态的生命和菜单项挂钩。
最好是有一个框架来自动管理状态。
目前“有状态的”web框架有:JSF,Wicket,Click,ASP.net,。。。
这些框架要么是把状态直接保存在服务器内存里,要么是用一个隐藏字段viewstate传给客户端。

[该贴被jackhatedance于2010-06-11 07:23修改过]

IceQi
2010-06-12 11:17
传统的web应用只在客户端进行显示工作,这样的结果是必须要在服务器端实现一个客户端的实例,在这个实例中进行客户端业务过程的维护。

本质上“服务--使用者”是任何分布式系统所共同的结构;但是在传统web应用环境下这个结构再次被细分成为“服务--使用者--显示者”,“服务--使用者”被一起集成到了服务器端。很多程序在实现的过程中却没有清晰的认识到这一点,真的将他们融合了进而造成了一些混乱。

其实web是一种很好的方式,非常便于应用系统的部署和维护。RIA是一种好的方向,通过职责的划分帮助我们更清晰和容易的建立起应用环境,浏览器端还需要提供相应的支撑环境来满足这种需求。

又想起来前些天看到有人在这里问如何进行系统划分,说起来很简单其实就是:找到必要的人,同时将每个人的职责归还给自己。在这里也是一样的。

banq
2010-06-22 11:04
相关讨论:

使用RabbitMQ使得Tomcat Sessions 变得更加云化

asklxf
2010-10-11 16:50
设计可伸缩系统的第一要点就是:不要使用Session
这样你才可能通过简单地堆服务器来扩展系统

spell
2011-04-21 15:21
简单分析:
1.session里面保存的信息是否能够得到及时的更新,比如你登录的时候取得列表,但是你又新增加了一条记录,是否会因为延迟导致问题。
2.大量的放在里面如果访问量大的话,那当然很占内存了,所以可以预见,一旦访问量高的话,很容易产生内存溢出了。
3.做负载均衡很不方便,对扩展有影响。

猜你喜欢