Go语言开发分布式轻松搞定高性能Crontab
——————————–
——————————–
cron的状态存储没有使用gfs和hdfs，而是作为这个cron分布式系统的子服务的一部分，因为这个系统的高可用级别需要尽可能减少对外部服务的依赖，高频而小文件读写需求不适合使用gfs和hdfs。
采用Fast Paxos算法设计和保证系统的高可用，去中心化，保证整个系统在大多数节点正常情况下都能稳定运行。
主要单元结构如下。选用Fast Paxos，有主从节点的概念。所有节点保存任务分配和调度信息，但只有master节点是cron服务的任务执行过程。如果主节点挂了，在组内重新选举，新的主节点可以接管上一个单元的任务执行，因为它已经保存并同步了上一个主节点的所有状态信息。整个执行单元通过rpc与任务调度中心进行通信。
googledistributedcronarch
从主节点的角度看任务执行流程如下。执行的开始和结束通过Paxos协议同步通知同组其他节点，只有leader可以和调度中心通信。
googlecron 启动进度图
主节点宕机，由从节点接管任务执行。对于一半要执行的任务，会有复杂的配置策略，通过与数据调度中心联动进行决策。危急情况的处理是复杂的，外部依赖的任务必须尽可能满足幂等设计，否则就需要在冒双重启动的风险和跳过启动的风险之间进行权衡。此外，为了任务的执行，整个系统还设计了很多策略，比如防止群振效应。（业务线凌晨开始执行任务，瞬间启动所有任务，影响集群可用性）
如果使用etcd来保存状态，其实并不需要原论文中的master-slave概念。所有节点都可以获取etcd中的数据和执行状态，只根据节点的角色和预先配置进行分片。执行不同的作业。 etcd选出的leader节点就是原论文中Datacenter scheduler的作用。只有这个领导节点执行作业存储、分配、管理和迁移。其他节点只是根据获取到的配置执行周期性的cron任务。当任一子节点宕机时，领导节点收到信息后可以将本节点的数据传输给其他节点。当leader节点宕机时，其他节点选举出新的leader节点，然后获取原leader存储的信息，重新分配任务。
