Clustering经典范文学习

  构造Cluster是架构师们实现Scalability与High Availability 的最直接用药。所以大家很多都会无意中使用Cluster的思想去设计自己的服务器。其实Java EE里的Clustering已经做得很熟很烂，大家如果烂熟各家vendor对Web，EJB，JNDI，JMS，WebService....的Cluster实现，再思考自己的烂摊子时，思路便快捷清晰，少很多与同僚们的无谓争论。

     JavaEE Cluster的经典范文是Sun的王昱写于2005年的Uncover the hood of J2EE Clustering Preface，更可贵的是dev2dev上的JadeYuan兄弟将它高质的翻成了中文。 

 一、所谓集群  

          目的就是以负载均衡(Load Balance)与失败转移(Failover) 实现可扩展性(Scalability)和高可靠性(High Availability)，主要实现的功能： 

Load Balance 算法主要有轮循、权重(根据服务器硬件配置的不同)和随机三种，但更酷的做法是基于负载(直接查探或者服务器主动报告它们的负载)。

Health Check心跳系统与发现协议。Server一般会主动定期多播报告自己状态，也会Ping对方来问候平安。比如Weblogic每10秒会向全世界发送一次心跳，如果有30秒没有收到某个服务器的心跳了(考虑到多播可能会丢失数据包)就可视对方为阵亡。

Session Replication 因为服务器会记录与特定用户的会话信息，Balancer应该把同一用户的请求定位到同一台服务器上。如果该服务器失效，就把该用户和会话信息转移到新服务器上。

除了Scalability 与High Availability，一个集群还应该对已有代码影响最小，对性能影响最小，配置与部署简单，以及运行时可监控。

 二、Web层群集 

    Balancer无非Apache/IIS插件，balance Servlet，硬件四层交换机三类，而讨论的重点在Session 信息的Replication 实现上，简单的分有全部服务器冗余备份，三三两两互为冗余备份，中央备份服务器三种模式。

              1.多服务器全冗余备份
              Tomcat的最为粗糙，最没有扩展性的做法，不提。Sun的怪怪的replacate的内存数据库法HADB可能也属于这种范畴。

              2.三三两两互为冗余备份
              Weblogic, Jboss and WebSphere 的做法，好主流。A会有B的数据，B会有C的数据，C会有B的数据，如果A出错，就会由C接替A的工作。这种做法的弊端是：
              1.要控制failover到备份服务器，Balancer的实现复杂度高。
              2.如果A出错，C就要瞬时承载A、C的操作，很可能将它压垮，针对这点，Weblogic的做法是针对每个session而不是每个Server选择备份服务器，把主备服务器A、B的名字写在用户Cookie里，如果A失效后，Balancer会根据cookie将用户转到服务器B。
              3.相对没有cluster的方案，需要花额外的时间和内存。

              文中没讲的Geronimo使用的WADI，应该也属于这种类型，不过更为灵活，详见Geronimo 叛逆者: 加入集群功能第1部分 和 第2部分。

              3. 中央备份服务器
              N+1模式，一个中央Server存放所有的Session，如果一台Server死了，接管的Server就从中央服务器restore相关数据。可以用数据库(很多应用服务器都支持的最简单，但最慢的模式)，也可以采用内存。这种方式好处是cluster服务器上不需要冗余内存，可以failover到任意服务器，cluster服务器全死了中央服务器都不死。坏处就是如果中央服务器死了...如果中央服务器的内存不够了.....另外，多了个restore的步骤。

        使用内存备份session时，Tomcat/JBoss使用的JavaGroups 是一个很好的工具，它的" Group membership protocols" and "message multicast"特性都非常有用。

        另外，无论使用内存还是数据库，都需要串行化Java对象，性能损耗厉害，所以JRun 就采用了Jini架构 ，而Tangosol Coherenc ，Terracotta这些Data Grid方案都提出了自己的session备份做法，整天显示着比传统方案快多少多少。Data Grid分布式缓存本身就是很Enterprise的功能，下篇blog再详述。 

三、EJB集群

从stub 调用实际EJB对象时，有三种方法实现负载均衡和fail over：

1. Smart Stub.在stub内维护有效列表，实现负载均衡逻辑，进行实效检测，BEA Weblogic and JBoss 采用。
2. IIOP Runtime Library ,Sun的JES 算法,把算法从客户端的stub移到客户端的IIOP Runtime
3. Interceptor Proxy，IBM做法，把算法移到了服务端，Location Service Daemon (LSD)。

在JNDI查找EJBHome，EJBHome Stub查找生成EJB实例，调用EJB方法三种时候都可以实现负载均衡，对statefull,stateless,entity bean，又有不同的做法。

EJB需要具有幂等性(在部署描述符中声明)才能failover。

四、其他集群

JMS集群，可以有多个broker组成集群(JBoss，如果要持久化Message，就要把原来嵌入式的数据库改为共享模式)，activeMQ还支持多个消费者组成集群，但每个消费者负责同一类的任务，比如订单队列的处理，Server A只处理图书类的订单，或只处理《Programming Ruby 2nd》的订单。

数据库集群有Oracle的RAC，但JDBC本身的failover能力很低，一旦connection 中断，resultset等对象都会失效，Weblogic的连接池会尝试重连。

五、走的更远

   Weblogic9/10的广域网群集和服务器迁移(有些服务在群集中只能有一个实例在运行，如果该实例失效，迁移到下一个实例)功能。

    如果只要单纯的load balance，不要fail over的话，使用纯硬件如F5已经足够，不需要在软件上做任何事情。

   群集有两种模式，一种是只在入口的Web层进行负载均衡，一种是Web层和对象层(EJB)分别进行负载均衡。

六、Cluster的神话

1.Failover可彻底避免错误
   JBoss的文档用了整整一章来警告你，真的需要http session复制吗？没有http session可以使效率提高很多，而有了的话，并不能避免所有错误。失败转移只能在两次调用间产生作用，在调用时产生的错误是无法恢复的，除非这是个幂等操作(如单纯的get()，而不是put()，无论如何重复操作结果都是一样的），否则，如果A上承载100用户，失败时有20个用户正在进行处理，则只有80个用户能逃出生天平安转移到B。

2.小心编写可集群的程序

1.http session要放能serilaze的对象，对象不要太大，变更时要显式的setAttribute().

2. 注意Cache的使用。如果每个JVM独立使用Cache，会否不一致，如果进行同步，注意开销。

3.不能使用静态变量，如在线用户数，要搞成分布式的 Cache。

4.外部资源如文件系统(一台机器上没有另外一台机器的文件)，存成DB或者使用SAN

5.特别服务：如timer服务，基于事件的服务