群集的存在意义

     近来为客户新做一个电子商务网站，部门经理天天给我说要把群集做进方案里，听的都吐了，在没有对于用户服务需求真正在进行好认真的分析的前提下，就将群集做进方案里，真的觉得很厌烦。
   
    我觉得即使对于中型的电子商务网站，也不一定需要群集，群集只会增加复杂度，甚至有可能延长用户请求的响应时间。同时限制Web应用的开发方案，如对于重型的基于SessionWeb-Flow方案，你就要考虑不能使用了。但对于电子商务网站，web-flow的应用很多，想像一个网站下单的过程，-查询－预订－登陆－填写需求-填写配送单－信用卡担保（或网上支付)-生成订单。使用wegbflow框架很方便，但在群集环境下，却有性能负担。
    我觉得基于apache的前导load-balancer方案，已经足够了，它可以持续将同一个Session的请求，分发给同一个worker进行处理。没有必要再使用群集来进行Session复制。

   

集群对session有两种吧

1、基于request的负载均衡

    该种方式下，负载均衡器 (load balancer)会根据各个node的状况，把每个 http request进行分发。使用这样的均衡策略，就必须在多个node之间复制用户的session，实时保持整个cluster的用户状态同步，这种操作被称为session复制(session replication)。Jboss的实现原理是使用拦截器(interceptor)，根据用户的同步策略拦截request，做同步处理后再交给server产生响应。

    该方法的优点是客户不会被绑定都具体的node，只要还有一个node存活，用户状态都不会丢失，cluster都能够继续工作。缺点是node之间通信频繁，响应速度有影响，多并发、高频操作的情况下性能下降比较厉害。

2、    基于用户的负载均衡

该种方式下，当用户发出第一个request后，负载均衡器动态的把该用户分配到某个节点，并记录该节点的jvm路由，以后该用户的所有request都会被绑定这个jvm路由，用户只会与该server发生交互，这种策略被称为粘性session(session sticky)。

该方法的优点是响应速度快，多个节点之间无须通信。缺点也很明显，某个node死掉以后，它负责的所有用户都会丢失session。

方案1,需要application server 支持，且开发时，要避免使用重型的Session来解决问题。

方案2,只需要apache来解决就可以了.

方案1 实际上需要 load-balance + session replication.

方案2 就只有load-balance了。

方案1应当是人们经常说的群集方案吧，必须要有软件支持吧。

方案2就是load-balance方案，可以基于硬件，也可以基于软件.

两个方案可以结合着来做：

前端apache使用session sticky方法保证同一用户总是导向同一个node，后端JBoss(注意不是Tomcat)配置异步session复制。

这样在通常情况下有apache保证请求可以达到hold该用户状态的node，而异步session复制有可以保证不影响性能，最后当该node fail以后，apache路由到其他node的时候，JBoss的异步复制又可以保证其他node已经拥有该用户状态。

不过对于大型的电子商务网站，apache基于HTTP协议层的load balance性能就撑不住了，这个时候可以考虑使用LVS，基于IP层协议的load balance，现在也支持session sticky(其实不需要基于session进行分发，只要基于IP进行分发就好了，用一个用户在一次session会话过程中不可能换IP的)。

就我阅读Tomcat的集群文档来说，集群(Cluster)和负载均衡(load balance)是两个问题，但通常是一起结合使用的。
Cluster是指几台服务器之间关联，一般主要指session 复制，使之成为一个整体，访问任何一台服务器都可以达到相同的效果；
Cluster建成后，需要利用Load balancer来执行请求的分发，就是分发到Cluster中具体的服务器上。

load-balance + asynchronized session replication 是个好主意，待俺尝试尝试，不过Tomcat也可以配置异步Session 吧。

另外，对于方案来说，有群集的概念其优势是显而易见的，可以支持fault-tolerant,性能更高，未来可以更容易的、低成本水平扩展，听上去更cool,等等，在商业方面优势比较大。
而对于开发者，其实了解一下群集对于开发有何限制是必要的，其实也没有多少限制，主要就是session里的任何对象都要实现Serializable接口，然后session里的东西要尽可能少。其他的东西都是可以在部署时考虑的东西。

所以，虽然可以实际上用不上群集，但学学实际无妨，还是有好处的。

我的意思，你不明白吗，就是不要session复制，避免技术复杂化带来的副作用？

在网站下单时，宁愿让整体的会话请求失败，也不愿意在会话的过程中间去失败。

我真的不太明白，群集对于开发者来说怎么样把技术复杂化了？实际上，群集，或者部署机器上用的什么高级UNIX服务器，等等，对于开发者来说都是透明的。

你认为session复制，会导致网站下单时，在中间过程失败么？我认为这种情况应该是群集去考虑的，如果他没有处理好这个问题，我认为他的确没有设计好，如果他处理好了，那么这个担心是因为你还不太了解session复制不会带来什么应用逻辑上的问题。

集群的问题在without ejb里，和精通ejb（第三版）都有非常详细的描述的，楼主不防一看