|
锁定老帖子 主题：J2EE集群之failover小点子
该帖已经被评为良好帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2011-08-22
session数据庞大起来后，效率怎样的~？
|
| 返回顶楼 | |
|
发表时间：2011-08-22
haojiahero 写道 session数据庞大起来后，效率怎样的~？ 没测试过， 感觉应该不影响效率吧 Session复制量很低的。 如果这样影响效率的话， Tomcat的交叉复制和JBoss的链式复制效率更低了 |
| 返回顶楼 | |
|
发表时间：2011-08-22
使用缓存服务器来缓存session这个是一般做分布式session的做法，但我觉得没有必要用那么多服务，只要何证缓存服务器有冗余就行了，一般写三份即可。不太可能三台缓存服务器都会down掉。
|
| 返回顶楼 | |
|
发表时间：2011-08-22
cdredfox 写道 使用缓存服务器来缓存session这个是一般做分布式session的做法，但我觉得没有必要用那么多服务，只要何证缓存服务器有冗余就行了，一般写三份即可。不太可能三台缓存服务器都会down掉。 恩、 缓存服务器数量无所谓了、 只要能保证随时至少有一台能用即可。 |
| 返回顶楼 | |
|
发表时间：2011-08-22
顶，值得一试
|
| 返回顶楼 | |
|
发表时间：2011-08-22
没做过互联网。悲剧
|
| 返回顶楼 | |
|
发表时间：2011-08-22
这个方案有点儿奇怪，首先为啥要用session?
很多事情cookie可以做的很好了，而且可以设定有效期，比session更灵活。 如果有需要缓存的东西，通过cookie直接关联到后面的memcached里面，可以自由定义数据结构，占用空间小，效率也高很多，也更容易管理。 |
| 返回顶楼 | |
|
发表时间：2011-08-23
梦秋雨 写道 如果只处理setAttribute/removeAttribute的话，如下情况是否漏掉：
request 1 : session.setAttribute("key1",new String[3]); request 结束后同步 request 2 : ((String[])session.getAttribute("key1"))[0] = "newString"; 没有set/remove，于是不同步？但是Session内容实际上已经变了。 我跟这位兄弟有着同样的疑问. 如果值是一个对象的话,我修改了对象中的属性,是否会触发session的复制 |
| 返回顶楼 | |
|
发表时间：2011-08-23
最后修改：2011-08-23
LikeEJB_CC 写道 梦秋雨 写道 如果只处理setAttribute/removeAttribute的话，如下情况是否漏掉：
request 1 : session.setAttribute("key1",new String[3]); request 结束后同步 request 2 : ((String[])session.getAttribute("key1"))[0] = "newString"; 没有set/remove，于是不同步？但是Session内容实际上已经变了。 我跟这位兄弟有着同样的疑问. 如果值是一个对象的话,我修改了对象中的属性,是否会触发session的复制 这个得看具体业务场景，session里面不要存敏感数据，即使分布式应用，定时备份即可 |
| 返回顶楼 | |
|
发表时间：2011-08-23
s929498110 写道 michael.softtech 写道 s929498110 写道 michael.softtech 写道 想法不错，不过有些地方还需商榷。 就我个人来看，存在如下问题： 1. 就像楼主说的，tomcat多的时候session 复制存在问题。假设现在有1000台Tomcast Server,楼主觉得应该 用多少memcached ? 如果少的话,每个memcached需要维护大量的session信息，而sessin本身是频繁变化的(通常情 况下session过期时间不会太久),那么memcached的工作就十分沉重. 如果memcached多的话，从楼主的思路来看,因为负载层面可能是在fail-over的情况下面随机选择另一个tomcat,那么为了保证肯定能取到session,就需要每个memcached-1都备份一份,这个备份效率能接受吗？ 2. 此外，多备份情况下，如何保证多备份数据在偶然情况下的session一致性? 比如某台memcached偶然网络出问题了， 恰好在这时进行了session invalidate操作，于是就产生了不一致性。这种不一致某些情况下会带来意想不到的后果。 所以我觉得这种思路研究研究还不错，如果真要使用的话，尚需验证。 我的想法是每个Tomcat对应一个Memcached、 这个Memcached不需要多大， 内存可能需要占用几十M吧。 它的CPU占用也是很低的，网上有过类似测试。 就是如果1000台Tomcat的话， 每台Tomcat上都安装一个Memcached（基本不占用多少系统资源，可能几十MB的内存，5%的CPU吧）。 然后每台Tomcat都将自己的 Session 按哈希码平均分布在其他999台Tomcat所在电脑的 Memcached 上。 也就是每台 Memcached 的真实Session备份数量是一台Tomcat的Session数量。 另外你说的备份时invalidate、 我的构思是Session备份是异步的， 即每个会话结束之后，都将需要更新缓存的Session放在一个队列里面， 这个队列由其他的后台线程负责更新缓存。 在Tomcat不宕机的情况下、 Tomcat是不需要从Memcached中读取Session的，只需要写入Session（备份）。 只有在某台Tomcat宕机了，才尝试从Memcached中读取宕机Tomcat中的Session备份。 嘿嘿， 不知道你明白我的意思没有， 表达能力挺挫的我 哦，你这样一说我就明白了。呵呵。 我开始以为不同memcached之间也有部分Session冗余哪。 其实你这个有点像独立的Session服务器了。最大的区别就是结合了tomcat的本地session进行了优化。 如果本地有，那么就不需要从Session服务器读取。 比单纯使用Session独立服务器有一定的效率提高。 我觉得这种情况下memcached最好单独部署,尤其是和tomcat的部署分开来. 同时Memcached的数量最好有一个合理的值。 每台Tomcat一个Memcached....这个应该还能优化吧呵呵。 完全可以把Tomcat和Memcached独立开来。 嘿嘿、 是吧。 但是我感觉为Memcached单独配置一台服务器不划算 哥们有经济头脑啊～赞一把嘿嘿 |
| 返回顶楼 | |
