|
|
|
|
@ -93,11 +93,13 @@
|
|
|
|
|
|
|
|
|
|
##### 一、去中心化vs中心化 |
|
|
|
|
|
|
|
|
|
######中心化思想 |
|
|
|
|
###### 中心化思想 |
|
|
|
|
|
|
|
|
|
中心化的设计理念比较简单，分布式集群中的节点按照角色分工，大体上分为两种角色： |
|
|
|
|
<p align="center"> |
|
|
|
|
<img src="https://analysys.github.io/EasyScheduler/zh_CN/images/master_slave.png" alt="master-slave角色" width="50%" /> |
|
|
|
|
</p> |
|
|
|
|
|
|
|
|
|
- Master的角色主要负责任务分发并监督Slave的健康状态，可以动态的将任务均衡到Slave上，以致Slave节点不至于“忙死”或”闲死”的状态。 |
|
|
|
|
- Worker的角色主要负责任务的执行工作并维护和Master的心跳，以便Master可以分配任务给Slave。 |
|
|
|
|
|
|
|
|
|
@ -114,6 +116,7 @@
|
|
|
|
|
<p align="center" |
|
|
|
|
<img src="https://analysys.github.io/EasyScheduler/zh_CN/images/decentralization.png" alt="去中心化" width="50%" /> |
|
|
|
|
</p> |
|
|
|
|
|
|
|
|
|
- 在去中心化设计里，通常没有Master/Slave的概念，所有的角色都是一样的，地位是平等的，全球互联网就是一个典型的去中心化的分布式系统，联网的任意节点设备down机，都只会影响很小范围的功能。 |
|
|
|
|
- 去中心化设计的核心设计在于整个分布式系统中不存在一个区别于其他节点的”管理者”，因此不存在单点故障问题。但由于不存在” 管理者”节点所以每个节点都需要跟其他节点通信才得到必须要的机器信息，而分布式系统通信的不可靠行，则大大增加了上述功能的实现难度。 |
|
|
|
|
- 实际上，真正去中心化的分布式系统并不多见。反而动态中心化分布式系统正在不断涌出。在这种架构下，集群中的管理者是被动态选择出来的，而不是预置的，并且集群在发生故障的时候，集群的节点会自发的举行"会议"来选举新的"管理者"去主持工作。最典型的案例就是ZooKeeper及Go语言实现的Etcd。 |
|
|
|
|
@ -160,7 +163,7 @@ EasyScheduler使用ZooKeeper分布式锁来实现同一时刻只有一台Master
|
|
|
|
|
##### 四、容错设计 |
|
|
|
|
容错分为服务宕机容错和任务重试，服务宕机容错又分为Master容错和Worker容错两种情况 |
|
|
|
|
|
|
|
|
|
######1. 宕机容错 |
|
|
|
|
###### 1. 宕机容错 |
|
|
|
|
|
|
|
|
|
服务容错设计依赖于ZooKeeper的Watcher机制，实现原理如图： |
|
|
|
|
|
|
|
|
|
|
dailidong
6 years ago