跳转到主要内容
SEO Title
A cluster management framework for partitioned and replicated distributed resources

架构


Helix旨在为分布式系统提供以下功能:

  1. 自动管理托管分区,复制资源的集群
  2. 软硬故障检测和处理
  3. 通过基于服务器容量和资源配置文件(分区大小,访问模式等)在服务器(节点)上智能放置资源来实现自动负载平衡
  4. 集中配置管理和自我发现,无需修改每个节点上的配置
  5. 群集扩展期间的容错和优化的重新平衡
  6. 管理节点的整个运营生命周期。无需停机即可添加,启动,停止,启用和禁用
  7. 监控群集运行状况并警告SLA违规
  8. 用于路由请求的服务发现机制

要构建这样的系统,我们需要一种机制来协调系统中不同节点和其他组件。这种机制可以通过软件来实现,该软件可以对集群中的任何变化做出反应,并提供一组使集群处于稳定状态所需的任务。该组任务将分配给群集中的一个或多个节点。 Helix用于管理群集中的各种组件。

Helix Design

分布式系统组件


通常,任何分布式系统集群都将具有以下组件和属性:

  1. 一组节点也称为实例
  2. 一组资源,可以是数据库,lucene索引或任务
  3. 将每个资源细分为一个或多个分区
  4. 每个资源的副本称为副本
  5. 每个副本的状态,例如 主人,奴隶,领袖,待命,在线,离线等


角色

并非分布式系统中的所有节点都将执行类似的功能。例如,一些节点可能正在处理请求,一些节点可能正在发送请求,而一些其他节点可能正在控制集群中的节点。因此,Helix按照系统中的特定角色对节点进行分类。

Helix根据职责将节点划分为3个逻辑组件:

  1. 参与者:实际托管分布式资源的节点
  2. 观察者:简单地观察每个参与者的当前状态并相应地路由请求的节点。例如,路由器需要知道托管分区的实例及其状态,以便将请求路由到适当的端点
  3. 控制器:观察和控制参与者节点的节点。它负责协调集群中的所有转换,并确保满足状态约束,同时保持集群稳定性

这些只是逻辑组件,可以根据系统要求进行部署。例如,控制器:

  1. 可以作为单独的服务部署
  2. 可以与参与者一起部署,但在任何给定时间只有一个控制器处于活动状态。

两者都有利有弊,稍后将对此进行讨论,并且可以根据系统需要选择部署模式。

群集状态元数据存储


我们需要一个分布式存储来维护集群的状态,并且需要一个通知系统来通知集群状态是否有任何变化。 Helix使用Apache ZooKeeper来实现此功能。

Zookeeper提供:

  1. 一种表示PERSISTENT状态的方法,直到删除为止
  2. 表示当创建状态的进程死亡时消失的TRANSIENT / EPHEMERAL状态的方法
  3. 当PERSISTENT和EPHEMERAL状态发生变化时的通知机制

ZooKeeper提供的命名空间非常类似于标准文件系统。名称是由斜杠(/)分隔的路径元素序列。 ZooKeeper命名空间中的每个节点(ZNode)都由路径标识。

有关Zookeeper的更多信息,请访问http://zookeeper.apache.org

状态机和约束


尽管资源,分区和副本的概念对于大多数分布式系统是通用的,但是将一个分布式系统与另一个分布式系统区分开来的一个方面是为每个分区分配状态的方式以及每个状态的约束。

例如:

  • 如果系统提供只读数据,那么所有分区的副本都是等效的,它们可以是ONLINE或OFFLINE。
  • 如果系统同时进行读取和写入,但必须确保写入仅通过一个分区,则状态将为MASTER,SLAVE和OFFLINE。写入通过MASTER并复制到SLAVE。可选地,读取可以通过SLAVE。

除了为每个分区定义状态之外,状态之间的转换路径可以是特定于应用程序的。例如,为了成为MASTER,可能需要首先成为SLAVE。这确保了如果SLAVE没有将数据作为OFFLINE-SLAVE转换的一部分,它可以从系统中的其他节点引导数据。

Helix提供了一种配置特定于应用程序的状态机以及每个状态的约束的方法。除了对STATE的约束外,Helix还提供了一种指定转换约束的方法。 (稍后会详细介绍。)

 OFFLINE  | SLAVE  |  MASTER
         _____________________________
        |          |        |         |
OFFLINE |   N/A    | SLAVE  | SLAVE   |
        |__________|________|_________|
        |          |        |         |
SLAVE   |  OFFLINE |   N/A  | MASTER  |
        |__________|________|_________|
        |          |        |         |
MASTER  | SLAVE    | SLAVE  |   N/A   |
        |__________|________|_________|

Helix Design

概念


Helix中使用以下术语来模拟状态机之后的资源。

  • IdealState:如果所有节点都已启动并运行,我们需要群集进入的状态。换句话说,满足所有状态约束。
  • CurrentState:集群中每个节点的实际当前状态
  • ExternalView:所有节点的CurrentState的组合视图。

Helix的目标始终是使系统的CurrentState(以及扩展名为ExternalView)与IdealState相同。有些情况可能并非如此:

  • 部分或全部节点已关闭
  • 一个或多个节点失败
  • 添加了新节点,需要重新分配分区

 

IdealState


Helix允许应用程序为每个资源定义IdealState。它包括:

分区列表,例如64
每个分区的副本数量,例如3
为每个副本分配的节点和状态
例:

  • Partition-1,replica-1:Master,Node-1
  • Partition-1,replica-2:Slave,Node-2
  • Partition-1,replica-3:Slave,Node-3
  • ... ..
  • ... ..
  • Partition-p,replica-r:Slave,Node-n

Helix附带了各种算法来自动将分区分配给节点。默认算法最小化将新节点添加到系统时发生的混洗次数。

当前状态


群集中的每个参与者都托管资源的一个或多个分区。每个分区都具有与之关联的状态。

Example Node-1

  • Partition-1, Master
  • Partition-2, Slave
  • ….
  • ….
  • Partition-p, Slave


ExternalView


外部客户端需要知道群集中每个分区的状态以及托管该分区的节点。 Helix为Spectators提供了一个系统视图作为ExternalView。 ExternalView只是所有节点CurrentStates的聚合。

  • Partition-1, replica-1, Master, Node-1
  • Partition-1, replica-2, Slave, Node-2
  • Partition-1, replica-3, Slave, Node-3
  • …..
  • …..
  • Partition-p, replica-3, Slave, Node-n


流程/工作流程


集群中的操作模式

节点进程可以是以下之一:

  • 参与者:进程在集群中注册自身,并对其队列中收到的消息进行操作并更新当前状态。示例:分布式数据库中的存储节点
  • 观众:该过程只对ExternalView中的变化感兴趣。
  • 控制器:此过程通过响应群集状态的更改并向参与者发送状态转换消息来主动控制群集。

参与者节点过程

 

  • 当参与者启动时,它会在LiveInstances下注册
  • 注册后,它会等待消息队列中的新消息
  • 当它收到消息时,它将执行消息中指示的所需任务
  • 任务完成后,根据任务结果更新CurrentState


控制器流程

 

  • 观看IdealState
  • 当参与者出现故障,出现,添加或被删除时通知。观看群集中每个参与者的短暂LiveInstance ZNode和CurrentState
  • 通过向参与者发送消息来触发适当的状态转换


观众过程

 

  • 当进程启动时,它会要求Helix代理通知ExternalView中的更改
  • 每当收到通知时,它都会读取ExternalView并执行所需的任务

 

控制器,参与者和观众之间的互动

Helix Architecture

核心控制器算法

 

  • 从ZooKeeper获取活动存储节点的IdealState和CurrentState
  • 计算所有Participant节点上每个分区副本的IdealState和CurrentState之间的增量
  • 对于基于状态机表的每个分区计算任务。可以在状态转换上配置优先级。例如,在MasterSlave的情况下:
  1.                    如果可能,尝试主控权转移而不违反约束
  2.                   分区添加
  3.                   分区下降
  • 如果可能,将并行转换任务添加到每个存储节点的相应队列中(如果添加的任务相互独立)
  • 如果转换任务依赖于正在完成的另一个任务,请不要添加该任务
  • 在参与者完成任何任务后,控制器会收到更改通知,并重新运行算法,直到CurrentState与IdealState匹配。


Helix ZNode布局


Helix以多个级别在群集名称下组织ZNodes。

顶级(在群集名称下)ZNodes都是Helix定义的,大写:

  • PROPERTYSTORE: application property store
  • STATEMODELDEFES: state model definitions
  • INSTANCES: instance runtime information including current state and messages
  • CONFIGS: configurations
  • IDEALSTATES: ideal states
  • EXTERNALVIEW: external views
  • LIVEINSTANCES: live instances
  • CONTROLLER: cluster controller runtime information

在INSTANCES下,每个实例都有运行时ZNode。一个实例按如下方式组织ZNodes:

  • CURRENTSTATES
    • sessionId
    • resourceName
  • ERRORS
  • STATUSUPDATES
  • MESSAGES
  • HEALTHREPORT

在CONFIGS下,有不同的配置范围:

  • RESOURCE: contains resource scope configurations
  • CLUSTER: contains cluster scope configurations
  • PARTICIPANT: contains participant scope configurations


下图显示了名为“test-cluster”的集群的Helix ZNode布局示例:

  Helix znode layout

 

原文 :https://helix.apache.org/Architecture.html

讨论: 请加知识星球【首席架构师圈】