现在如果要构造一个真正在生产环境上可使用的可靠的系统，基本都离不开集群的概念，总的来说集群是指由若干互相独立的机器通过高速网络组成的一个整体服务，整个集群的内部实现相对外部是透明的，对外部而言它就像一个独立的服务器。要使若干机器协同工作不是一件简单的事，其核心是如何在多机器之间进行通信及各种任务调度使之协同工作。
在工程上常见的两种集群是——负载均衡集群和高可用集群。
负载均衡集群（Load Balance Cluster），随着系统的处理量的不断增加，很快到达一台机器的处理极限，所以需要更多的机器来分担处理，负载均衡集群一般是通过一定的分发算法把访问流量均匀分布到集群里面的各个机器上进行处理，理想的集群是通过添加机器使处理能力达到线性增长，但现实中往往处理过程并非是无状态的，会涉及到一些共享状态变量，所以当集群数量达到一定程度后处理能力并不能按线性增长且可靠性可能也会降低。关于负载均衡集群如何协调分配分发请求的问题，即可以使用专门的负载均衡硬件如F5，也可以使用软件级别的方式实现负载均衡如LVS、HAProxy等。
高可用集群（High Available Cluster），高可用集群通过软件把若干机器连接起来，这种集群更偏重的是当集群中某个机器发生故障后能通过自动切换或流量转移等措施来保证整个集群对外的可用性。在实际运用中很经典的就是mysql数据库的主从节点，一般情况如果是一主多从我们会使用读写分离措施，主节点负责执行写操作而从节点执行读操作，一旦主节点发生故障后系统将自动从多个从节点中选举出一个节点作为主节点继续对外提供服务，保证了服务的高可用。高可用集群与负载均衡集群一般不会绝对地划分开，我们不会将一台机器什么也不做就放着就等其他机器出故障再去候补，为了使用地更加高效可以把这些备用（standby）的机器用于负载均衡，故障发生后再接管故障节点的职责。
1.Tribes简介
http://blog.csdn.net/column/details/tribes.html
【集群通信组件Tribes之整体介绍】
http://blog.csdn.net/wangyangzhizhou/article/details/46755585
把若干机器组合成一个集群，集群为了能协同工作，成员之间的通信是必不可少的，当然可以说这也是集群实现中重点需要解决的核心问题，一个强大的通信协同机制是集群的基础。
简约地说，Tribes是一个具备让你通过网络向组成员发送和接收信息、动态检测发现其他节点的组通信能力的高扩展性的独立的消息框架。在组成员之间进行信息复制及成员维护是一个相对复杂的事情，因为不仅要考虑各种通信协议还要有必要的机制提供不同的消息传输保证级别，且成员关系的维护要及时准确，同时针对IO不同场景需提供不同的IO模式，这些都是组成员消息传输要遇到的需要深入考虑的几点。而Tribes很好地将点对点、点对组的通信抽象得即简单又相对灵活。
Tribes拥有消息可靠的传输机制，它默认基于TCP协议传输，TCP拥有三次握手机制保证且有流量控制机制，另外在应用层面的消息可靠保证分为三个级别：
①NO_ACK级别，这是可靠级别最低的方式，使用此种级别时则认为Tribes一旦把消息发送给socket的发送队列则认为发送成功，尽管传输过程中发生异常导致接收方可能没有接收到，当然这种级别也是发送最快的方式。
②ACK级别，这是最推荐使用的一种方式，它能保证接收方肯定接能收到消息，Tribes向其他节点发送消息后只有接收到了接受者的确认消息才会认为发送成功，这种确认机制能在更高层面保证消息可靠性，不过发送效率会有影响，因为每个消息都需要确认，得不到确认的会重发。
③SYNC_ACK级别，这种方式不仅保证传输成功还保证执行成功，Tribes向其他节点发送消息后接收者接收到不马上返回ACK确认而是对接收到的消息进行处理，直到处理成功才返回ACK确认。如果接收成功处理失败接收者会返回ACK_FAIL给发送者，发送者将会重发。当然这种级别消息发送效率是最低最慢的。
整个Tribes的设计核心可以用上图表示，在IO层有三个重要的模块，
其中MembershipService 模块主要负责组成员关系的维护，包括维护现有成员及发现新成员，这些工作都是模块自动运行完成，你无需关心组成员的维护工作；
ChannelSender 模块负责向组内其他成员发送消息及其各种机制的详细实现；ChannelReceiver 模块用于接收组内其他成员发送过来的消息及其各种机制的详细实现。
消息的可靠性就是通过ChannelSender及ChannelReceiver的协同得到不同级别的保证的。
拦截器栈提供了在消息传送到应用层之前对消息进行一些额外的操作，例如对某些信息进行过滤编码等等操作；
最后到应用层，多数情况下我们只需关注应用层的东西即能使用起来，应用层面主要就是一些监听器，所以只要实现监听器里面指定的方法即可以对IO层传输上来的消息做逻辑处理。
【Tribes 设计核心】
拦截器、监听器的引入都是经典的模式，抽象一个底层作为数据处理层，实现各种复杂的通信及机制，而拦截器则是对底层数据的一种统一额外加工处理，监听器则作为接口提供应用层对数据做业务逻辑处理，组成了一个优雅的设计方案。
2.集群成员维护服务——MembershipService
http://blog.csdn.net/wangyangzhizhou/article/details/46849875
一个集群包含若干成员，要对这些成员进行管理就必须要有一张包含所有成员的列表，当要对某个节点做操作时通过这个列表可以准确找到该节点的地址进而对该节点发送操作消息。如何维护这张包含所有成员的列表是本节要讨论的主题。
成员维护是集群的基础功能，一般划分一个独立模块或层完成此功能，它提供成员列表查询、成员维护、成员列表改变事件通知等能力。由于tribes定位于基于同等节点之间的通信，所以并不存在主节点选举的问题，它所要具备的功能是自动发现节点，即新节点加入要通知集群其他成员更新成员列表，让每个节点都能及时更新成员列表，每个节点都维护一份集群成员表。如图，节点1、节点2、节点3使用组播通过交换机各自已经维护一份成员列表，且他们隔一段时间向交换机组播自己节点消息，即心跳操作。当第四个节点加入集群组，节点四向交换机组播自己的节点消息，原理三个节点接收到后各自把节点四加入到各自的成员列表中，而原来三个节点也不断向交换机发送节点消息，节点四接收到后依次更新成员列表信息，最终达到四个节点都拥有四个节点成员信息。
看下tribes的集群是如何设计实现以上功能的，其成员列表的创建维护是基于经典的组播方式实现，每个节点都创建一个节点信息发射器和节点信息接收器，让他们运行于独立的线程中。发射器用于向组内发送自己节点的消息，而接收器则用于接收其他节点发送过来的节点消息并进行处理。要使节点之间通信能被识别就需要定义一个语义，即约定报文协议的结构，tribes的成员报文是这样定义的，两个固定值用于表示报文的开始和结束，开始标识TRIBES_MBR_BEGIN 的值为字节数组84, 82, 73, 66, 69, 83, 45, 66, 1, 0，结束标识TRIBES_MBR_END的值为字节数组84, 82, 73, 66, 69, 83, 45, 69, 1, 0，整个协议包结构为：开始标识（ 10bytes ） + 包长度（ 4bytes ） + 存活时间（ 8bytes ） +tcp 端口（ 4bytes ） + 安全端口（ 4bytes ） +udp 端口（ 4bytes ） +host 长度（ 1byte ） +host （ nbytes ） + 命令长度（ 4bytes ） + 命令（ nbytes ） + 域名长度（ 4bytes ） + 域名（ nbytes ） + 唯一会话 id （ 16bytes ） + 有效负载长度（ 4bytes ） + 有效负载（ nbytes ） + 结束标识（ 10bytes ） 。成员发射器按照协议组织成包结构并组播，接收器接收包并按照协议进行解包，根据包信息维护成员表。
第一步要先执行加入组播成员操作，接着分别启动接收器线程、发射器线程，一般接收器要优先启动。发射器每隔1秒组织协议包发送心跳，组播组内成员的接收器对接收到的协议报文进行解析，按照一定的逻辑更新各自节点本地成员列表，如果成员表已包含协议包的成员则只更新存活时间等消息。
Tribes利用上述原理维护集群成员，并且由独立模块MembershipService提供成员的相关服务，例如获取集群所有成员相关信息等。
3.平行的消息发送通道——ChannelSender
http://blog.csdn.net/wangyangzhizhou/article/details/46945525
前面的集群成员维护服务为我们提供了集群内所有成员的地址端口等信息，可以通过MembershipService可以轻易从节点本地的成员列表获取集群所有的成员信息，有了这些成员信息后就可以使用可靠的TCP/IP协议进行通信了。这节讨论的正是实际中真正用于消息传送通道的相关机制及实现细节。
如下图，四个节点本地都拥有了一张集群成员的信息列表，这时节点1有这么一个需求：为了保证数据的安全可靠，在往自己的内存存放一份数据的同时还要同步到其他三个节点的内存中。节点1有一个专门负责发送的组件ChannelSender，首先从成员列表中获取其他三个节点的通信地址和端口，再分别向此三个节点建立TCP/IP通道发送数据，其他节点有一个负责接收数据的服务，将数据更新到内存中。
最理想的状态是发送给节点2、3、4都成功了，这样从整体看来ChannelSender像是提供了一个多通道的平行发送方式，所以也称为平行发送器。但现实中并不能保证同一批的消息往所有节点发送都成功，有可能发送到节点3时因为某种原因失败了，而节点2、4都成功了，这时通常要采取一些策略来应对，例如重新发送。Tribes所使用的策略是优先进行若干次尝试发送，若干次失败后将向上抛出异常信息，异常信息包含哪些节点发送失败及其原因，默认的尝试次数是1次。
为确保数据确实被节点接收到，需要在应用层引入一个协议保证传输的可靠性，即是通知机制，发送者发送消息给接收者，接受者接收到后返回一个 ACK **表示自己已经接收成功。**Tribes中详细的协议报文定义如下：START_DATA（7bytes）+消息长度（4bytes）+消息长度（nbytes）+END_DATA（7bytes）。START_DATA为数据开始标识，为固定数组值70,76,84,50,48,48,50，END_DATA为数据结束标识，为固定数组值84,76,70,50,48,48,51，ACK_DATA表示通知报文，为固定数组值6,2,3。所以如果传输的是通知报文的话即为START_DATA+ACK_DATA的长度+ACK_DATA+END_DATA。所以整个集群的消息同步如下图，节点1通过ChannelSender发送消息给节点2、3、4，发送成功的判定标准就是节点2、3、4返回给节点1一个ack标识，节点1接收到了则认为发送成功。
为提高通信效率这里默认使用了NIO模式而非BIO模式（也可设置为BIO模式），使用NIO模式能统一管理所有通信的channel，避免了等待一个通道发送完毕另一个通道才能发送，如果逐个通信将导致阻塞IO时间很长通信效率低下。另外平行发送的过程需要一个锁保证消息的正确发送，例如有data1、data2、data3三个数据需要发送，应该是一个接一个数据包发送的而不能data1发一部分data2发一部分。
这节介绍了Tribes如何向集群其他成员发送数据，通过本地获取其他成员节点的地址和端口，再通过平行消息发送通道发送给其他节点，其中有ack机制和重发机制保证数据成功接收。
4.消息接收通道——ChannelReceive
http://blog.csdn.net/wangyangzhizhou/article/details/47059701
与消息发送通道对应，发送的消息需要一个接收端接收消息，它就是ChannelReceiver。接收端负责接收处理其他节点从消息发送通道发送过来的消息，实际情况如图每个节点都有一个ChannelSender和ChannelReceiver，ChannelSender向其他节点的ChannelReceiver发送消息。本质是每个节点暴露一个端口作为服务端监听客户端，而每个节点又充当客户端连接其他节点的服务端，所以ChannelSender就是充当客户端的集合，ChannelReceiver充当服务端。
集群消息复制过程中，每个节点ChannelReceiver负责接收来自其他节点的消息，假设一个n节点的集群，一般情况下每个ChannelReceiver对应n-1个连接，因为集群之间的通信连接都是长连接，长连接有助于提高通信效率，如下图，4个节点的集群，node1的ChannelReceiver的客户端连接数为3，分别是node2、node3、node4三个节点作为客户端发起的socket连接。这三个节点产生的数据会通过此通道同步到node1节点，同样地，node2的ChannelReceiver拥有node1、node3、node4的客户端连接，这三个节点产生的数据也会同步到node2节点。Node3、node4也拥有三个客户端连接。为提高处理效率，此处还是使用NIO处理模型。
除此之外，再接收操作中为了优化性能采取了很多措施，例如引入任务池，即是把接收任务提前定义好放入内存中，接收时可直接获取使用而不用再实例化；例如一次获取若干个报文进行处理，即使用nio模式读取消息到缓冲区后直接处理整个缓冲区的消息，它可能包含若干个报文；网络IO需要优化的地方及手段都比较多，tribes确实已经做了很多优化方面的工作。
5.通道拦截器——ChannelInterceptor
拦截器应该可以说是一个很经典的设计模式，它有点类似于过滤器，当某信息从一个地方流向目的地的过程中，可能需要统一对信息进行处理，如果考虑到系统的可扩展性和灵活性通常就会使用拦截器模式，它就像一个个关卡被设置在信息流动的通道中，并且可以按照实际需要添加和减少关卡。Tribes 为了在应用层提供对源消息统一处理的渠道引入通道拦截器，用户在应用层只需要根据自己需要添加拦截器即可，例如，压缩解压拦截器、消息输出输入统计拦截器、异步消息发送器等等。
拦截器的数据流向示意图可以参考前面的tribes简介章节，数据从IO层流向应用层，中间就会经过一个拦截器栈，应用层处理完就会返回一个ack给发送端表示已经接收并处理完毕（消息可靠级别为SYNC_ACK），，最底层的协调者ChannelCoordinator永远作为第一个加入拦截器栈的拦截器，往上则是按照添加顺序排列，且每个拦截器的previous、next分别指向前一个拦截器和下一个拦截器。
Tribes的拦截器整体设计就如上面，整个拦截器的执行顺序如下，当执行写操作时，数据流向GzipInterceptor -> ChannelCoordinator -> Network IO；当执行读操作时，数据流向则为Network IO -> ChannelCoordinator -> GzipInterceptor。理解了整个设计原理后对于tribes的整体把握将会更加深入。
6.应用层处理入口——MembershipListener与ChannelListener
http://blog.csdn.net/wangyangzhizhou/article/details/47376023
Tribes为了更清晰更好地划分职责，它被设计成用IO层和应用层，IO层专心负责网络传输方面的逻辑处理，把接收到的数据往应用层传送，当然应用层发送的数据也是通过此IO层发送，
数据传往应用层后必须要留一些处理入口供应用层进行逻辑处理，而考虑系统解耦，这个入口最好的方式是使用监听器模式，在底层发生各种事件时触发所有安装好的监听器，使之执行监听器里面的处理逻辑。这些事件主要包含了集群成员的加入和退出、消息报文接收完毕等信息，所以整个消息流转过程被分成两类监听器：
一类是跟集群成员的变化相关的监听器 MembershipListener ；
另外一类是跟集群消息接收发送相关的监听器 ChannelListener 。
应用层只要关注这两个接口就行了，写好各种处理逻辑的监听器添加到通道中即可。
【应用层入口】
我们可以在应用层自定义若干监听器并且添加到GroupChannel中的两个监听器列表中，GroupChannel其实可以看成是一个封装了IO层的抽象容器，它会在各个适当的时期遍历监听器列表中的所有监听器并调用监听器对应的方法，即执行应用层定义的业务逻辑，至此完成了数据从IO层流向应用层并完成处理。
两种类型的监听器给应用层提供了处理入口，应用层只需关注逻辑处理，而其他的IO操作则交由IO层，这两层通过监听器模式串联起来，优雅地将模块解耦。
7.如何使用Tribes进行数据传输
http://blog.csdn.net/wangyangzhizhou/article/details/47684053
8.Tomcat使用Tribes同步会话
Tomcat集群中最重要的交换信息就是会话消息，对某个Tomcat实例某会话做的更改，要同步到集群中其他Tomcat实例的该会话对象上，这样才能保证集群中所有的实例的会话数据保持一致。
如果集群中有一个Tomcat实例的会话变了，它会通过会话管理器将改变的动作消息封装成消息然后调用集群对象Cluster，通过Cluster将消息发送出去，同时Cluster有依赖于Tribes。最后消息其实就是交由Tribes真正发送出去的。通信过程是以ClusterMessage为对象进行传输的，它会先序列化再进行传输，到其他Tomcat实例的时候会反序列化，消息由Tribes接收之后向Cluster上传。最后达到会话管理器，它根据动作消息同步会话；
所以Cluster其实就是实现了ChannelListener的监听器，当Tribes接收到消息之后，就会调用此监听器的messageReceived方法处理逻辑，此方法又会继续向上通知Manager的messageDataReceived方法，在此方法内完成会话同步处理逻辑；
9.Tomcat使用Tribes部署集群应用
http://blog.csdn.net/wangyangzhizhou/article/details/52167894
集群应用部署是一个很重要的应用场景，设想一下如果没有集群应用部署功能，每当我们发布应用时都要登陆每台机器对每个tomcat实例进行部署，这些工作量都是繁杂且重复的。于是需要一种功能可以在集群中某实例部署后，集群中的其他tomcat实例会自动完成部署。
集群部署主要分两部分内容。
- 第一部分是关于应用传输问题，主要是关于在tomcat中如何一个web应用传输到其它tomcat实例上；
- 第二部分是应用部署方式及应用更新方式，主要关于在tomcat中如何以集群同步方式部署一个web应用，以及集群实例在接收到新版本web应用时如何进行更新。
tomcat的集群是基于tribes网络框架的。
关于第一部分传输的问题，其主要是使用tribes进行数据传输，但它有一个地方需要考虑，常见的小数据都可以一次性直接发送，但web应用一般都是比较大，不可能一次性将其全部读到内存再直接写入到套接字中，所以需要分开多次传输。
部署的几个主要组件如图，tomcat集群中每个实例都会包含Cluster组件，它包含了专门用于集群部署的ClusterDeployer集群部署器，而且ClusterDeployer组件也是建立在tribes之上。假如将web应用部署到中间的tomcat实例上，它的ClusterDeployer组件则会读取该web应用war包文件，然后通过tribes向集群的其他两个tomcat实例发送，前面也说到不可能一次性全部读取，所以读取时使用了一个缓冲区，它默认是10k字节大小的，所以一次最多能传输10k字节数据，这些数据会被封装成FileMessage对象进行传递。集群其他tomcat实例的ClusterDeployer将所有FileMessage接收后组成一个完整的war包文件。
【集群应用中的消息传输】
另外，从发送端到接收端存在多个缓冲队列并且可能还有多线程操作，所以说在发送端的应用层按顺序将文件数据一份一份发送，在接收端的应用层并不能保证按顺序接收到。为了解决乱序的问题，需要在传输的消息中引入消息编号，即对每个FileMessage进行累加编号，例如发送时每个FileMessage对象按顺序编码从1开始累加，在接收端就可以从编码为1的FileMessage对象开始处理，接着处理编码为2的FileMessage，以此类推，这样就保证了数据的顺序性了，保证了拼凑的数据最终的准确性。这样就解决了web应用传输的问题了，往下看第二部分。
集群中应用如何部署以及更新
集群中应用如何部署及如何更新的？如下图，每个tomcat实例的集群部署器ClusterDeployer都包含了一个WarWatcher组件，这个组件主要用于监听某个目录下是否有新的应用包或某个应用包是否被有更新，一旦监听到这些事件则把新的应用同步到集群中其他实例上。这个过程大致如下：
①集群中某实例的WarWatcher监听watchDir目录下部署了新应用xx.war包。
②将新应用xx.war包先复制到本实例的deployDir部署目录下。
③集群部署器ClusterDeployer将xx.war包传递到另外一个tomcat实例。
④另外一个tomcat实例的ClusterDeployer将xx.war包暂时存放到tempDir目录。
⑤xx.war包完整接收后重新命名到deployDir目录下。
关于那三个目录，watchDir目录属于监听目录，一旦有war包部署或更新就会被检测到；tempDir目录用于存放临时接收到的war包数据，不能直接保存到deployDir目录，异常情况下可能把原来的war包覆盖了且又没能接收完整的新war包，所以需要临时目录；deployDir目录是真正的部署目录，war包从tempDir目录转移到deployDir目录一般使用renameTo操作，它不用真正地进行文件copy操作，不管文件多大都可以在瞬间完成操作。
至此，tomcat集群如何进行集群应用部署的整个工作过程及其机制已经全部完毕，总的来说就是通过监听实例的某个目录，一旦发现新应用就同步到集群其他实例上，传输时引入缓冲机制避免文件过大，而且通过对消息编号避免消息乱序，接收时先暂存应用到某目录，避免网络异常发生文件覆盖情况。