Clustering经典范文学习.doc

Clustering经典范文学习Posted on October 19, 2010 by lowerthan60 /calvinxiu/archive/2007/05/10/1602891.aspx构造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 Runtime3. 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的对象，对象不要太大，变更时要