今天谈下集群和高可用方面的内容。在前面我谈过IT基础架构的高可用性设计，其核心的一个特点就是在运行期间没有任何的单点故障。因此在基础部署架构设计的时候，往往就有两个思路，其一就是实现简单的HA高可用，一种就是实现集群，同时在集群基础上同时实现高可用。因此今天对这方面的内容做下简单整理。

HA高可用架构

HA高可用是最基础的一种高可用架构，一般应用在数据库，管理节点，负载均衡节点等。一主一备，只有一个节点提供能力，但是在主节点宕机后能够自动切换到备用节点。对于任何类型的中间件或应用服务器都可以搭建高可用架构，但是前提是共享存储，因为高可用架构只会做浮动IP切换，而不会去做底层数据的同步。

HA高可用架构搭建过程中，一般又存在手工切换和自动切换两种情况。

如果要做到自动切换，那么必须配合心跳检查，即通过脚本进行心跳检查，在心跳检查出现异常的时候进行IP地址的切换操作。

对于操作系统级别的HA高可用性软件当前大部分都属于商用和收费软件，包括类似红帽的RedHat Cluster Suite，虽然是可以免费下载安装，但是也需要购买相应的技术服务，否则后续无法得到相应的技术支持和版本升级服务等。

心跳检查

心跳检查HeartBeart在搭建高可用架构的时候经常会使用。核心目的就是发现节点故障或问题，同时进行自动切换操作。

比如可以通过HaProxy+KeepAlived来搭建一个高可用架构。在数据库中采用MySql Dual Master架构的时候，我们也会使用HaProxy+KeepAlived来搭建一个提供VIP的数据库高可用架构。

心跳检查一般包括了心跳监测部分和资源接管部分，心跳监测可以通过网络链路，发送ping或连接请求，如果失败或超时达到一个阈值，就认为对方失效，这时需启动资源接管模块来接管运 行在对方主机上的资源或者服务。

集群和负载均衡

如果当前有6个Tomcat应用服务器节点，我们统一接入到Ngnix或F5硬件负载均衡设备。那么6个节点是否就构成了一个完整的Tomcat集群？

上面这种情况实际只实现了负载均衡能力，而没有实现集群管理能力。

一个完整的集群必须具备集群管理能力，其核心包括了节点的心跳检查，配置文件信息的分发，高可用保障，请求负载均衡，统一的集群节点监控和管理等。

比如一个应用要部署，我们可以在管理节点进行统一处理，部署包会自动部署到所有集群节点，或者说我们可以在管理端对单个或整体集群节点进行重启等操作。

也就是说集群一般会存在管理节点，管理节点对集群提供上面说的管理能力。负载均衡能力你可以不用集群本身的负载均衡，比如请求分发和均衡仍然通过接入F5硬件设备完成等。

当前中间件或软件一般存在两种情况，一种就是自己实现Admin集群管理能力，一种是基于开源的Zookeeper或Etcd来实现集群管理能力。比如在dubbo中会采用Zookeeper来作为注册中心，kurbernetes中则采用Etcd进行集群管理。

在分布式任务协调场景下，两者实际提供能力基本一致，对比如下：

其中Zookeeper 使用 java 开发的，被 Apache 很多项目采用。而Etcd 使用 go 语言开发的，主要是被 Kubernetes 采用。Zookeeper 非常稳定，是一个著名的分布式协调系统，Etcd 是后起之秀，前景广阔。

基于Zookeeper或Etcd来实现集群管理节点

如果你自己实现一个集群，完全可以基于Zookeeper或Etcd来实现集群管理节点。在集群管理节点的管理中本身包括如下核心内容。

心跳检查：对于心跳检查如下异常的节点能够自动剔除或者触发该节点自动进行重启，重启后正常才能够重新加入集群。

部署或配置分发：具备进行统一部署或配置分发能力，只需要在管理节点更新部署或配置信息，该信息能够自动分发到所有的集群节点确保一致性。

软负载均衡：具备基本的路由分发和负载均衡能力。

分布式锁：当存在多节点同时触发抢占某一个任务的时候，具备分布式锁能力，确保该任务只能够被一个节点处理，如果该节点处理异常又能够快速释放锁。其它监听节点可以快速获取锁并进一步处理该任务。

集群和分布式

很多时候这两个概念是在混用，但是本身还是有一点区别。简单来说对于集群即所有的节点全部都是相同的，包括部署的内容，具备的能力，然后构成一个整体对外服务；但是对于分布式来说则可能各个节点本身具备分工，共同处理最终完成一个任务。

比如常见的负载均衡，多个节点本身完全相同，则是典型的集群架构；而对于一个大矩阵的计算，可能要分解为多个部分，拆分到不同的机器进行计算则类似于分布式架构。简单来说类似Master-Slave架构下，Master对任务进行分解到Slave进行计算，完成后再到Master进行汇总即可理解为典型的分布式架构。

集群节点假死问题

对于中间件集群，往往存在一种情况即节点处理任务的时候被Hang住或者叫假死。在这种情况下节点心跳检查正常，但是无法处理正常分发过来的请求，或者请求处理全部超时。

因此心跳检查还有一个重点就是需要去判断集群节点是否出现假死。

如果仅仅是类似tomcat应用服务器，你可以直接去curl http访问tomcat首页看是否正常返回。但是如果是判断应用功能是否正常，那么还涉及到数据库，在这种情况下一般需要单独写一个用于心跳检查的接口进行心跳检查，看这个接口在心跳检查过程中能否正常返回。

动态扩容或动态分区

简单来说即集群节点不论是新增加，还是因为故障异常等原因下线减少的时候，对于新的请求路由分发，或者新任务的获取都能够再次基于当前可用节点数进行重新分配。

集群能够动态扩容，但是当新增加节点的时候并不会对已经在集群其它节点运行的经常进行重新分配，而是仅仅对新增加的需求进行重新分配计算。在分布式数据库集群的实现中可以看到，这类集群涉及到底层持久化数据，因此当增加节点的时候往往涉及到数据本身的ReSharding重新计算，这个动作本身是相对复杂的，一般不建议自动处理。

集群管理节点至少3个节点以上奇数部署

在进行集群架构部署的时候，可以看到管理或Master节点一般都要求3个节点或以上的奇数个节点进行部署。在这里进行简单说明如下。

在前面已经谈到Master节点肯定不能单节点部署，否则就存在单点故障，那么我们容易想到就是2个节点冗余架构部署。

注意如果Admin或Master节点往往并不是简单的保证自己的高可用性，而且还需要承担对管理的Slave节点的管理和心跳监控职责。那么2个节点部署的时候，如果2个节点进行心跳监控返回的状态不一致，那么应该听谁的？因此为了避免这种情况必须要有一个奇数的投票机制来决策，因此至少需要3个节点来进行管理节点的部署。

分布式任务调度

当构建一个分布式集群的时候，实际上又存在两种情况。

一种情况是本身集群节点被动等待信息分发，等待经过集群路由过来的访问请求；另外一种情况是集群节点主动去获取或抢占任务并进行处理。

如果是第二种情况则涉及到分布式任务调度。

分布式任务调度简单来说就是有多个任务处理节点也组成集群，但是这些节点主动去抢占和处理管理或调度阶段的任务列表信息，并进行加锁，如果处理失败或者处理节点宕机又能够快速的释放锁方便其它任务处理节点处理。

当然对于这种情况，你也可以采用Zookeeper具备的分布式锁功能来实现。但是对于分布式任务调度本身又是一个细分方向，有专门的分布式任务调度开源解决方案。

如开源的xxl-job分布式调度框架

从图上也可以看到分布式调度框架本身也具备节点注册管理，分布式锁，心跳检查等关键能力。因此如果是一个任务处理类分布式集群构建，那么采用开源的分布式调度框架进行扩展往往是一种更好的处理方案。

即在分布式任务调度框架中，我们将任务的产生和任务的处理两个事件解耦，一个进程独立运行产生待处理的任务，而另外进程运行则是通过并发和锁机制抢占和处理任务，如果处理任务过程中出现异常又能够自动释放任务。