标签：逻辑   name   region   高性能   temp   一个   nta   span   ffline   

Hadoop

• 在hadoop中，zk主要用来实现HA(High Availability)。这部分逻辑主要集中在hadoop common的HA模块中，HDFS的NameNode和Yarn的ResourceManager都是基于此HA模块来实现自己的HA功能的。同时，在YARN中又特别提供了zk来存储应用的运行状态。

YARN

• Yarn主要由ResourceManager、NodeManager、ApplicationMaster和Container四部分组成。
• 其中最核心的就是RM，它作为全局的资源管理器，负责整个系统的资源管理和分配。

RM单点问题

• RM是YARN中非常复杂的一个组件，负责集群中所有资源的统一管理和分配，同时接受各个NM的资源汇报信息，并把这些信息按照一定的策略分配给各个app。
• ResourceManager HA的解决方案就是使用 Active/Standby模式的RM HA架构。
  
• 可以看到，在运行期间会有多个RM存在，但只有一个处于Active状态，其他的是standby。当active节点无法正常工作时，其余处于standby的节点则会通过竞争选举产生新的节点。

主备切换

• • RM使用基于zk实现的ActiveStandbyElector组件来确定RM的状态：Active或Standby。
    具体做法如下：
    1. 创建锁节点：在zk上有一个类似于/yarn-leader-election/pseudo-yarn-rm-cluster的锁节点，所有rm在启动时都会去竞争一个lock子节点/yarn-leader-election/pseudo-yarn-rm-cluster/ActiveStandbyElectorLock，该节点是临时节点。
    2. 注册Watcher监听：所有standby状态的rm都会向/yarn-leader-election/pseudo-yarn-rm-cluster/ActiveStandbyElectorLock节点注册一个节点变更的Watcher监听，利用临时节点的特性，能快速感知到Active状态的RM的运行状态。
    3. 主备切换：当active节点不可用时，其对应zk上的Lock节点也会随之被删除，其他standby状态的rm都会接收到zk server的watcher事件通知，然后重复步骤1。
  • 以上，实际上就是通过临时节点 + Watcher事件通知来实现的。
  • HDFS中的NameNode和RM模块都是使用ActiveStandbyElector组件来实现各自的HA的。

Fencing(隔离)

• 在分布式环境中，经常会出现诸如单机“假死”的情况。所谓“假死”是指机器由于网络闪断或是自身负载过高(常见的有GC占用时间过长或CPU的负载过高等)而导致无法正常地对外进行及时响应。
• 在上述主备切换过程中，我们假设RM集群由rm1和rm2组成，且rm1为active，rm2为standby。某一刻rm1发生“假死”现象，此时zk认为rm1挂了，从而主备切换，rm2称为active。但是随后，rm1恢复了正常，其依然认为自己还处于active。那么就出现了我们常说的分布式“脑裂”(Brain-Split)现象，即存在多个处于Active状态的rm各司其职。
• Yarn引入了Fencing机制来解决上述问题，即借助zk数据节点的ACL权限控制机制来实现不同rm之间的隔离。
• 具体做法很简单：在主备切换过程中，多个rm之间通过竞争创建锁节点来实现主备状态的确定。这个过程中，有一点需要改进：创建的根节点必须携带zk的ACL信息，目的是为了独占该根节点，以防止其他RM对该节点进行更新。
• 具体来说：
  • RM1出现假死之后，zk就会将其创建的锁节点移除，此时RM2会创建相应的锁节点，并切换为Active状态。RM1恢复之后，会试图去更新zk的相关数据，但是此时发现自己没有权限更新zk的相关数据节点。从而rm1自动切换到Standby状态。

RM状态存储

• 在RM中，RMStateStore能够存储一些RM内部状态信息，包括Application以及它们的Attempts信息、Delegatioln Token及Version Information等。
• RMStateStore中绝大多数信息都是不需要持久化存储，因为很容易从上下文信息中将其重构出来。
• 在存储的设计方案中，提供了三种可能的实现，分别如下：
  • 基于内存实现，一般用于日常开发测试；
  • 基于文件系统的实现，如HDFS；
  • 基于zk的实现。
• 由于这些状态数据量都不大，因此hadoop官方建议基于zk来实现状态信息存储。
• 在zk上，rm的状态信息都存储在/rmstore这个根节点上，其数据节点的组织结构如下：
  

HBase

• HBase是一个基于Hadoop文件系统设计的面向海量数据的高可靠性、高性能、面向列、可伸缩的分布式存储系统。
• 与大部分分布式NoSQL数据库不同的是，HBase针对数据写入具有强一致性，甚至包括索引列也实现了强一致性。
• HBase整体架构如下图：
  
• 可以看到，在整个HBase架构体系中，zk是串联起HBase集群与client的关键所在。
• 早期Hbase没有引入zk时，存在一系列问题：
  • RegionServer挂掉时，系统无法及时得知信息，client也无法知晓，因此服务难以迁移至其他RegionServer上
  • 类似的问题都是缺少相应的分布式协调组件。
• 下面从以下几个方面讲解zk在HBase中的应用场景。

系统冗错

• （系统冗错其实就是监控rs
• 当HBase启动时，每个RegionServer都会到zk的/hbase/rs节点下创建一个信息节点(rs状态节点)，例如/hbase/rs/[Hostname]，同时HMaster会监听该节点。
• 当某个rs挂掉时，zk会因为在一段时间内无法接受其心跳信息(即Session失效)，而删除掉该rs对应的rs状态节点。同时，HMaster收到zk的NodeDelete通知，并立即开始冗错工作：
  • HMaster会将该RegionServer所处理的数据分片(Region)重新路由到其他节点上，并记录到Meta信息中供client查询。
• 那么，为什么不直接让HMaster来负责RegionServer的监控呢？是因为通过心跳机制来管理rs状态会使HMaster的负载随着系统容量而不断增大。并且，HMaster可能挂掉，因此数据还需要持久化。

RootRegion管理

• 对HBase集群而言，数据存储的位置信息是记录在元数据分片，也就是RootRegion上的。每次client发起新的请求，需要知道数据的位置，就会去查询RootRegion，而RootRegion自身的位置是记录在zk上的。当RootRegion发生变化，比如Region的手工移动、Balance或是RootRegion所在server发生故障等时，就能通过zk来感知到这一变化并做出一系列容灾措施。

Region状态管理

• Region是HBase中数据的物理切片，每个Region中记录了全局数据的一小部分。
• 对一个分布式系统而言，Region是会经常发生变更的。一旦Region发生移动，它必然会经历Offline和重新Online的过程。
• Offline期间数据是不能被访问的，并且Region的这个状态必须被全局知晓，否则可能会出现事务性的异常。

分布式SplitLog任务管理

• 当某台RS挂掉时，由于总有一部分新写入的数据还没有持久化到HFile中，因此在迁移该RegionServer的服务时，一个重要的工作就是从HLog中恢复这部分还在内存中的数据(WAL)。
• 而这部分工作最关键的一步就是SpitLog，即HMaster需要遍历该RS的HLog，并按Region切分成小块移动到新地址下，并进行数据的Replay。
• 由于单个RS的日志量相对庞大(可能有数千个Region，上GB的日志)，一个快速恢复的可行方案就是将这个处理HLog的任务分配给多台rs来共同处理。
• 因此需要一个持久化组件来辅助HMaster完成任务的分配。当前的做法是，在zk上创建一个splitlog节点，将rs和待处理的region之间的映射关系存放到该节点。然后各个rs到该节点上领取任务并在执行后将成功or失败的信息更新到节点。
• 整个过程中，zk担负了分布式集群中相互通知和信息持久化的角色。

Kafka

<zk在大型分布式系统中的应用>

标签：逻辑   name   region   高性能   temp   一个   nta   span   ffline   

原文地址：http://www.cnblogs.com/wttttt/p/7652852.html