可以在同一局域网不同的机器上运行 Keeper，实现高可用和分散式计算。在任务数量比较少的情况下，个人经验是 1000 个以下，没必要使用集群，单机即可满足计算要求。如果要满足基本的高可用要求，可使用两台或者三台机器即可。
安装要求：
完整的安装说明请参考 Qross 系统安装
Keeper 调度集群区别于对外提供服务的多机负载均衡，如 Spring Cloud，也区别于提供数据计算和存储服务的多机集群，如 Hadoop。Keeper 是分散式集群，不提供对外高负载请求，也不提供统一数据计算。Keeper 不同的机器做不同的事，只是为了将任务在不同的机器上调度起来。Keeper 多机的目的一是提供高可用，二是在海量任务场景下分散单机计算的压力。
Keeper 实现的是对等集群，不同于 Hadoop 的主从集群。对等集群中每台机器的地位相同，协同工作也不需要 ZooKeeper 协调。增加节点和减少节点只要在对应的机器上启动 Keeper 或关闭 Keeper 即可，无需要进行其他操作。
Keeper 节点内部由 Akka 提供支持，节点之间通过 Akka Http 进行通信。为了最大简化配置工作，没有使用 Akka Remoting，对等集群也用不到 Akka Cluster。
Keeper 节点之间使用 Qross 数据库（MySQL）做为传输数据的纽带，所有协同算法均与数据库相关。
Akka Http 不仅为节点之间提供通信支持，也为与 Keeper 操作提供 Restful 接口服务。所以，Keeper 节点的端口非常重要。
Keeper 的分散式运算主要体现在执行调度任务上，其他操作大部分都在一个节点上完成。所以在多机场景下，需要有“锁”来实现资源访问限制，“锁”既是多线程也是多机程序的关键机制。Keeper 提供了心跳锁来锁定需要限制访问的资源。因为心跳一分钟进行一次，所以心跳锁的锁定时间为一分钟，下一分钟自动解锁。心跳锁有创建任务锁、检查任务锁等。
为了均衡多个节点的负载，不至于让某个节点太忙或太闲，Keeper 设置了一个负载评分机制。让最闲的机器干更多的工作。公式由 3 部分构成，计算方式使用全概公式。
64%。32%。4%。根据以上参数计算出一个数值，再除以节点最闲状态下的最大分值，即最终负载评分，百分制，保留两位小数。
上面提到心跳锁，很多操作不需要多个节点执行，只需要一个节点执行即可。对等集群模式下需要不同的节点进行资源抢夺，来决定本次心跳谁来进行相关的操作。算法过程可理解为：在心跳时，节点根据自己的负载评分等待一段时间，这个时间是负载评分乘以 10，即最闲的节点等待时间最短，最忙的节点等待时间最长，最长时间不超过1秒。最闲的节点因为等待时间最短，所以会首先为本次操作加锁，其他节点就不能再进行本次的操作了。这样可以保证每次都是让最闲的节点干活儿。
上面提到最闲的节点来完成任务创建等只需要一个节点即可完成的工作，在创建完任务后需要进行任务分发。分发算法是这样的：首先要知道每台机器的可用执行器数量，将待分发任务依次分发，每次分发之前查找可用执行器最多的节点，即最闲的节点，分发任务给这个最闲的节点（有可能是本机）并且可用执行器数量减1，保证每次都是向最闲的节点分发任务。如果指定的任务接收节点不通，那么则将这个不通的节点踢出列表并且查找下一个最闲节点。如果所有节点都不通，则本机执行这个任务。
在 Keeper 中有一个系统检查组件在每分钟心跳时，首先获取所有可用节点列表，并且依次通过 Http 端口向这个可用节点依次发送请求，对于连接不通的节点将会在数据库进行记录不通次数，不通次数达到 3 次则会被标记为“离线”。
上面互检算法中已经提到了判断离线的基本逻辑，再完整说明一下。在 Keeper 中，有多种情况需要节点之间进行通信，例如检查连通性、分发任务等。基本逻辑就是，当 A 节点检查到 B 检查不通时，就在数据库中记录 B 节点的断线次数，当达到 3 次时，就会把 B 节点标记为“离线”状态，再后面的检查、分发等操作就再与 B 节点无关。可以通过全局事件来设置和编程节点离线时的操作，如预警等。当 B 节点再次被激活时，离线状态会被修改成“在线”，断线次数会被重置。
除了自动创建任务和运行任务外，Keeper 还提供了许多交互操作，这些交互操作可以手动控制任务，而且这些操作与多机算法基本无关。分两种情况，第一种情况是通过 @KEEPER_HTTP_SERVICE 查找最闲的节点并执行操作，主要操作有立即运行、重启等；第二情况在与任务关联的节点上执行操作，包含的操作有：中断、获取日志、删除等。
参考链接
