该帖已经被评为精华帖
|
|
---|---|
作者 | 正文 |
发表时间:2007-05-23
用楼主的方案,只要memcached服务器不down机,failureover是可以做到的。
虽然memcached比较稳定,但是一样可能down机。不知道memcached的集群好不好做failureover。回头看看文档去 ;-) |
|
返回顶楼 | |
发表时间:2007-05-23
balaschen 写道 streamfly 写道 把list等业务数据或大对象放到session是不好的事情,但如果真的要来不同的页面之间传递,那该放到什么地方呢?很想知道!
一般来说,我会做一个sessionContext,使用theadlocal来保存当前线程上下文相关数据,如果数据是在多个请求之间共用,可以把这部分数据放到缓存或数据库(主要看你的这部分数据有无持久化的需要),这样不仅可以在view层共享,也可以在业务逻辑层访问这部分数据。另外增加一个CloseSessionListener,在session失效时清除不必要的数据(也可以利用cache的失效机制) 把数据放到数据库里就有点浪费了,毕竟用session传递的数据一般情况下是做为中间信息供不同页面之间访问或处理的,而且这些数据一般是从数据库里或通过其他方式读取出来的。另外,放到缓存里,我也觉得有点问题,因为我每次用session注销一个属性,如果cache可以用,一般情况下是不成功的。而且如果,放到session里面的数据或大对象的值在不同页面间传递的时候发生变化,并且,如果从session里读取数据和往session重新对同一属性赋值发生在相同的页面,用sessionContext有没有问题? |
|
返回顶楼 | |
发表时间:2007-05-23
session的属性本身就是一个hashmap(可以去看tomcat的session实现),并不是什么特别的技术,自己用theadlocal来管理,实现了线程安全,你爱怎么操作都行,至于把数据放内存还是放数据库,当然要看你的业务了。
如果数据仅仅是在不同页面之间传递的中间信息,应该放到request而不是session中。 |
|
返回顶楼 | |
发表时间:2007-05-23
pupi 写道 用楼主的方案,只要memcached服务器不down机,failureover是可以做到的。
虽然memcached比较稳定,但是一样可能down机。不知道memcached的集群好不好做failureover。回头看看文档去 ;-) memcached目前版本不支持群集,memcached本身的设计是cache server,不是db,而且要求及其轻量级和高速,自然没有考虑群集。对于一个cache server来说,down掉并没有什么大不了的事。如果是session server则另当别论了,像专业的session server 如tangosol就能很好的支持群集。如果想做到memcached的群集,除非修改源代码。还有一个简单的解决方法,就是通过客户端api实现,update操作时,同事往两台服务器写,读取则随机挑选一台,类似CJDBC提供的数据库群集方案,不过如果写操作频繁,肯定是要影响性能,尤其是对于session server来说,session有个失效时间,每次request时都必须更新其最后访问时间,等于每个request都需要对memcached server执行写操作,性能应该会受到相当的影响。 |
|
返回顶楼 | |
发表时间:2007-05-24
codeutil 写道 加入oscache的目的减少对memcached的访问次数。 假设启动了20个tomcat, 假如某个attribute,序列化之后的内容长度为10k, 在30分钟内被读取了100次,修改了两次, 如果只使用memcached的话,需要向memcached读取100次, 产生100*10=1M的网络流量, 而使用了oscache的话, 只需要向memcached读取三次,在属性值发生变化的时候,其它tomcat将会收到2*20次缓存失效的jgroups消息。 这样的开销是远远低于对memcached的不停访问的,也减少了序列化和反序列化的开销。 如果是作为session server,session的最后访问时间每次访问都要update,这样开销应该更大 |
|
返回顶楼 | |
发表时间:2007-05-24
楼主可以介绍一下选memcached的原因吗?
Terracotta最近好像挺火的,也提供了Tomcat httpsession cache的方案。 另外,只看楼主文章,好像是20个tomcat的oscache里都有其他19个tomcat的session,这样子扩展性在内存方面就成问题了:) |
|
返回顶楼 | |
发表时间:2007-05-24
江南白衣 写道 楼主可以介绍一下选memcached的原因吗?
Terracotta最近好像挺火的,也提供了Tomcat httpsession cache的方案。 另外,只看楼主文章,好像是20个tomcat的oscache里都有其他19个tomcat的session,这样子扩展性在内存方面就成问题了:) 每一个server的oscache应该有全部的session,用terracotta管理的session也是全局的,差别在于自动更新session为全局的session,少了cache的副本,还有只更新变化部分,性能会好一点,jboss的pojocache也有类似的特性,应该可以换掉oscache |
|
返回顶楼 | |
发表时间:2007-05-24
1.memcached虽然是cache server,但是把cache有效期指定长一些(比如1天),在现实情形中,就等同于是个永久的存储空间了(session挂一整天的,基本不不是普通使用系统的用户了)
2.tomcat a最初只存放自己所拥有的session,只有在a挂了之后,session被转移到了 tomcat b,这个时候b才会从memcached 读取属性存访本地,在这种情况下,假设a重新启动了,则 session又将转回a.在这个时候,如果在a上,session的属性值发生变化,通过oscache的jgroups消息,可以让b存放的属性值缓存实效,以此避免a又挂了之后,用户被转到b的时候读取到旧的属性值。 oscache的缓存机制是在本地缓存,只有缓存失效消息才会广播给所有tomcat。 因此基本不存在20个tomcat里都存在有其它19个tomcat的session的情况(当然其它19 个tomcat都挂了,只剩下一个tomcat了,才会是这样的情形),不然的话就成tomcat 自身的复制机制了. 江南白衣 写道 楼主可以介绍一下选memcached的原因吗?
Terracotta最近好像挺火的,也提供了Tomcat httpsession cache的方案。 另外,只看楼主文章,好像是20个tomcat的oscache里都有其他19个tomcat的session,这样子扩展性在内存方面就成问题了:) |
|
返回顶楼 | |
发表时间:2007-05-24
从实际应用情况出发,没有必要update这个时间。
如果是作为session server,session的最后访问时间每次访问都要update,这样开销应该更大 |
|
返回顶楼 | |
发表时间:2007-05-24
codeutil 写道 1.memcached虽然是cache server,但是把cache有效期指定长一些(比如1天),在现实情形中,就等同于是个永久的存储空间了(session挂一整天的,基本不不是普通使用系统的用户了)
2.tomcat a最初只存放自己所拥有的session,只有在a挂了之后,session被转移到了 tomcat b,这个时候b才会从memcached 读取属性存访本地,在这种情况下,假设a重新启动了,则 session又将转回a.在这个时候,如果在a上,session的属性值发生变化,通过oscache的jgroups消息,可以让b存放的属性值缓存实效,以此避免a又挂了之后,用户被转到b的时候读取到旧的属性值。 oscache的缓存机制是在本地缓存,只有缓存失效消息才会广播给所有tomcat。 因此基本不存在20个tomcat里都存在有其它19个tomcat的session的情况(当然其它19 个tomcat都挂了,只剩下一个tomcat了,才会是这样的情形),不然的话就成tomcat 自身的复制机制了. 江南白衣 写道 楼主可以介绍一下选memcached的原因吗?
Terracotta最近好像挺火的,也提供了Tomcat httpsession cache的方案。 另外,只看楼主文章,好像是20个tomcat的oscache里都有其他19个tomcat的session,这样子扩展性在内存方面就成问题了:) 我觉得这与集群下的分配机制有关,比如在LVS情况下,我们可以将一个客户端的请求持续分配到一个Real Server上,这样情况下,不需要集中Session存储都可以,另外的情况,比如Apache或是lighttpd的blance机制,用户的请求就不一定分配到哪个应用服务器上,这样就需要Session的集中存储管理,无论只使用memcached或是memcached+oscache,都要求对Session的写操作尽量的少。 |
|
返回顶楼 | |