wordpress用户中心插件seo优化工作

本文主要探讨yarn集群的高可用容错方案和容错能力的探讨。涉及RM和NM相关组件，在出现单机故障时相关的容错方案。

更多关于分布式系统的架构思考请参考文档关于常见分布式组件高可用设计原理的理解和思考

---

1. RM高可用

1.1 选主和HA切换逻辑

RM（ResourceManager）的HA机制主要依靠zk完成。整体的逻辑跟HDFS的NN逻辑整体上一致，也略有差别，可以参考 HDFS节点故障的容错方案

相同点
1， RM使用zk的临时锁节点（ActiveStandbyElectorLock）进行选主
2，其他节点的watch机制跟hdfs的逻辑也一致

不同点
1， RM没有另外涉及zkfc辅助选主，而是RM自己完成了相关的逻辑
2，YARN集群没有涉及fencing逻辑。

2. NM高可用

NM是运行在单个节点上的代理 ，主要职责有

1. 管理Hadoop集群中单个计算节点，功能包括与ResourceManager保持通信
2. 管理Container的生命周期、监控每个Container的资源使用(内存、CPU等）情况、追踪节点健康状况、管理日志和不同应用程序用到的附属服务等
3. 向ResourceManager汇报各个Container运行状态和节点健康状况，并领取有关Container的命令（比如清理Container）。

2.1 感知NM节点异常

NM启动后通过RPC函数ResourceTracker#registerNodeManager向RM注册，之后将被加入到NMLivenessMonitor中进行监控。它必须周期性通过RPC函数ResourceTracker#nodeHeartBeat向RM汇报心跳以表明自己还活着，如果一段时间内(默认是10min）内为汇报心跳，则RM宣布它已经死亡，所以正在运行在它上面的Container将被回收。

当RM判断NM宕机后，需要

1. RM剔除对应的NM，并将异常NM上的container标记死亡，后续container不会被分配到对应的NM
2. 通知AM，告知异常NM上的container已经死亡，由AM决定下一步的任务行为。

2.2 异常NM上的任务处理

由于在yarn集群中，任务的管理是通过AM进行管理的，因此RM感知到NM异常后，标记对应的containier死亡，并需要通知对应的AM。NM或者RM并不负责运行在上面的app运行状态，而是由AM来决定下一步动作（AM在跟RM申请一个NM执行container，还是标记app失败等）。

4. 疑问和思考

4,1 RM感知NM异常需要10min，对于app来说是否太长了？

视情况而定。由于RM感知NM异常，需要10min的时间，然后才会通知AM，这个时间相对于大多数任务而言还是比较长的。如果任务对数据的实时性要求很高，建议AM创建container后，container主动给AM汇报心跳，来决定业务行为，能够感觉相关的业务需求来进行开发。通常flink、spark任务都是过该思路进行开发的。

5. 参考文档

• 一文搞定Journal Node原理