spring的集群问题的疑惑

现在公司里有一个项目，想做spring的集群，现在他们的做法是一台webserver，比如说tomcat，然后把spring的应用部署到多个applicationserver上，然后webserver通过ejb的rmi来调用applicationserver上的spring程序，就是说webserver和spring应用程序其实是在多个不同的jvm上的，他们之所以这么做说是为了提高性能,请教有经验的老手,能不能这样做，有没有人做过类似的东西，这样做有什么样的优点和缺点。

如果直接把webserver和spring应用部署到一个jvm上，然后将多台相同的部署情况的机子做集群可以吗，哪一个更好呢？？？

评论

17 楼 zgd 2006-09-22  

可惜sticky session还要遇上一个问题，重启tomcat

16 楼 galaxystar 2006-09-20  

谢谢codeutil,黏性的会话，是不错的选择！

15 楼 codeutil 2006-09-20  

stickysession 就是用来干这个的，不然怎么会叫 黏性会话。

galaxystar 写道

谢谢robbin,mod_proxy_balancer还算好配置，真的很不错！
2.2的apache改进很大啊！

另，横向的配制，是不是指session只跟随一台，以后所有请求跟着这台服务器走？

14 楼 galaxystar 2006-09-20  

谢谢robbin,mod_proxy_balancer还算好配置，真的很不错！
2.2的apache改进很大啊！

另，横向的配制，是不是指session只跟随一台，以后所有请求跟着这台服务器走？

13 楼 ahuaxuan 2006-09-20  

robbin写道：
不要用分布式，优点没有，缺点一大把，应该用横向的cluster，就是apache＋tomcat那种。这方面讨论可以看看《without EJB》，Rod Johnson分析的非常详尽。



without ejb，255页，关于deployment clustering部分写到：当控制权从一台单独的转发服务器中转到具体处理的服务器后，所有的调用都是本地的（通过引用调用）

这句话里的转发服务器可以看作是apache，具体的处理服务器就是tomcat，所以合理的集群方式应该是一台apache＋多个tomcat形成的集群

12 楼 codeutil 2006-09-20  

效果很好，当然用户也不多，平均同时在线才1600左右。
唯一麻烦的是目前的web部署方式不是很好，
导致更新文件的时候需要复制20次。
然后一个一个重起。

最大的优点，就是tomcat个数基本上可以无限增加。

ahuaxuan 写道

codeutil 写道

我们现在一个系统启动了20个tomcat，每个tomcat设置的512m内存。
每个tomcat都有自己完整的spring的东西。

这种集群确实是大家比较认可的集群方式，请问同学，效果怎么样啊

11 楼 robbin 2006-09-20  

ahuaxuan 写道

robbin终于来了，我觉得我们公司的做法不太合理，请教robbin，这样做有什么样的缺点和优点

不要用分布式，优点没有，缺点一大把，应该用横向的cluster，就是apache＋tomcat那种。这方面讨论可以看看《without EJB》，Rod Johnson分析的非常详尽。

10 楼 ahuaxuan 2006-09-20  

codeutil 写道

我们现在一个系统启动了20个tomcat，每个tomcat设置的512m内存。
每个tomcat都有自己完整的spring的东西。

这种集群确实是大家比较认可的集群方式，请问同学，效果怎么样啊

9 楼 codeutil 2006-09-20  

我们现在一个系统启动了20个tomcat，每个tomcat设置的512m内存。
每个tomcat都有自己完整的spring的东西。

8 楼 ahuaxuan 2006-09-20  

robbin终于来了，我觉得我们公司的做法不太合理，请教robbin，这样做有什么样的缺点和优点

7 楼 codeutil 2006-09-20  

ProxyPass / balancer://tomcatcluster/  lbmethod=byrequests stickysession=JSESSIONID  nofailover=Off timeout=5  maxattempts=3
ProxyPassReverse / balancer://tomcatcluster/

<Proxy balancer://tomcatcluster>
BalancerMember ajp://192.168.0.36:8009 smax=10 max=10 ttl=5 timeout=5 acquire=3  route=tomcat1
BalancerMember ajp://192.168.0.36:8029 smax=10 max=10 ttl=5 timeout=5 acquire=3  route=tomcat2
BalancerMember ajp://192.168.0.36:8039 smax=10 max=10 ttl=5 timeout=5 acquire=3  route=tomcat3
</Proxy>

robbin 写道

galaxystar 写道

一台apache作为均衡负载，多台应用服务器部署tomcat,然后，通过apache给tomcat分配请求！（今天刚知道apache2.2.0新的代理模块mod_ajp）
问题是session绑定到单台机子上，还是一登录后多台机子状态复制，这个比较难搞！
建议用cookie，而不是用session！通过过滤器，对所有需要登录的页面先做cookie提取，封装成对象填入session!
这样，应用里还是取的session!
还有，你这样的部署，肯定是分布式应用了，数据库服务器族与cache服务器族，搜索服务器族与应用服务器族之间怎么协调，消息群发，线程，容灾也有N多问题！且各个族又可能是单独的群集！
如果你都能架设出来，也不容易啊！

用apache2.2的mod_proxy_balancer，支持session sticky，我以前给出过配置，搜索一下。

6 楼 robbin 2006-09-20  

galaxystar 写道

一台apache作为均衡负载，多台应用服务器部署tomcat,然后，通过apache给tomcat分配请求！（今天刚知道apache2.2.0新的代理模块mod_ajp）
问题是session绑定到单台机子上，还是一登录后多台机子状态复制，这个比较难搞！
建议用cookie，而不是用session！通过过滤器，对所有需要登录的页面先做cookie提取，封装成对象填入session!
这样，应用里还是取的session!
还有，你这样的部署，肯定是分布式应用了，数据库服务器族与cache服务器族，搜索服务器族与应用服务器族之间怎么协调，消息群发，线程，容灾也有N多问题！且各个族又可能是单独的群集！
如果你都能架设出来，也不容易啊！

用apache2.2的mod_proxy_balancer，支持session sticky，我以前给出过配置，搜索一下。

5 楼 galaxystar 2006-09-20  

让前端服务器只做均衡负载！
均衡负载服务器一般不做应用，只做分发，宕机的机会比较少！
就算宕机，容灾的服务器可以马上接过它的责任！或者直接将请求给tomcat应用服务器

4 楼 ahuaxuan 2006-09-20  

那合理的做法应该是什么样子的呢

3 楼 galaxystar 2006-09-20  

我的看法是，你说的群集，只会浪费服务器资源！应用程序只将spring的分开？WEB层一台服务器调那么多应用服务器，性能上有很大的提升吗？？一定数量级的并发，一台web能吃得消？WEB的责任太大了吧？
WEB服务器宕机，你整个应用宕机哦！

2 楼 ahuaxuan 2006-09-20  

一台apache作为均衡负载，多台应用服务器部署tomcat,然后，通过apache给tomcat分配请求！（今天刚知道apache2.2.0新的代理模块mod_ajp）
问题是session绑定到单台机子上，还是一登录后多台机子状态复制，这个比较难搞！
建议用cookie，而不是用session！通过过滤器，对所有需要登录的页面先做cookie提取，封装成对象填入session!
这样，应用里还是取的session!

---------------------------

你说的是第二种情况的集群吧

1 楼 galaxystar 2006-09-20  

一台apache作为均衡负载，多台应用服务器部署tomcat,然后，通过apache给tomcat分配请求！（今天刚知道apache2.2.0新的代理模块mod_ajp）
问题是session绑定到单台机子上，还是一登录后多台机子状态复制，这个比较难搞！
建议用cookie，而不是用session！通过过滤器，对所有需要登录的页面先做cookie提取，封装成对象填入session!
这样，应用里还是取的session!
还有，你这样的部署，肯定是分布式应用了，数据库服务器族与cache服务器族，搜索服务器族与应用服务器族之间怎么协调，消息群发，线程，容灾也有N多问题！且各个族又可能是单独的群集！
如果你都能架设出来，也不容易啊！