以一张具有代表性的架构风格展开本篇论述
一般在这种架构中,主节点所负责的工作主要有
- 跟踪从节点状态
- 分配任务到从节点,并跟踪任务的有效性(任务是否正常执行完成)
此时,我们需要关注三个问题
- 主节点崩溃
如果主节点发生了错误,那么整个系统将无法分配新的任务;对于已经失败的任务也无法进行重新分配。 - 从节点崩溃
如果从节点发生错误,已经分配的任务将无法执行完成。 - 主从之间的通信发生故障
如果主从之间通信故障,主节点将无法感知从节点的任务执行状态,并且从节点也无法接收新的任务。
主节点崩溃
对于这个问题,我们需要有一个备份主节点(backup master)。当主要主节点(primary master)崩溃时,backup master能够接管primary master的任务,进行故障转移。接管意味着,新的master能够切入到旧的master崩溃时的状态。此时,就需要旧的master失效时的一些信息,而这个信息已经无法从旧的master进行获取,需要从其他地方获取,即通过Zookeeper进行获取。
还有另外一种情况。当主节点负载很高,导致消息传递发生了延迟,导致backup master误认为primary master已经失效,此时backup master会成为第二个primary master。同时由于网络等原因,一些从节点无法与第一个primary mastter通信,而与第二个primary master建立了主从关系。这种情况被称之为脑裂(split-brain)。简单来讲,脑裂就是系统中两个或多个部分开始独立工作,导致整体行为不一。
所以需要一种方法来处理主节点失效的情况,并且避免脑裂。
从节点崩溃
主节点分配任务到有效的从节点,从节点执行任务并报告任务的执行状态。如果从节点崩溃了,主节点需要将尚未完成的任务重新派发到其他从节点。所以,主节点需要具备检测从节点失效的能力,并确定那些从节点有效以便于派发任务。
主从之间的通信发生故障
如果一个从节点与主节点的网络连接断开,重新分配一个任务可能会导致两个从节点执行相同的任务。如果一个任务允许多次执行,我们在进行任务再分配时可以不用关心从节点是否完成了该任务。如果一个任务不允许,那么我们的应用需要适应多个从节点执行相同任务的可能性。
通过以上描述,总结出主从架构有以下几点需求
- 主节点选举
- 崩溃检测
- 组成员关系管理:主节点需要知道哪一个从节点具备执行任务的能力。
- 元数据管理。用于保存任务的分配状态和执行状态。
ZooKeeper提供了实现这些原语的关键机制,使得开发者可以更加关注应用本身的业务逻辑。
什么是原语?
比如说我写到这里的时候,饥肠辘辘,想吃宫保鸡丁,于是我开始自己动手做这道菜。
- 切(原语):首先,需要将鸡肉切成丁,将辣椒切成段。
- 炒(原语):其次,需要在锅中加热油,然后炒鸡肉。
- 调味(原语):最后,在炒的过程中,需要加入调料,如酱油、糖、醋等。
通过这些基本的“原语”(准备食材和烹饪操作),可以组合它们来完成一道美味的菜肴。在计算机中,原语就是构建更复杂系统和程序的基本构件。