一、概述：
根据 Ambari Server 架构 文章中的介绍，由于 Ambari Server 和 Ambari Agent 之间是通过 HTTP 短连接进行通信，所以 Server 无法把需要执行的 Command，直接推送给 Agent，而是需要把命令存储在 ActionQueue 中，
然后 Agent 通过定期发送 Heartbeat 请求，把 Command 拉过去执行，并通过下次的 Heartbeat 请求，返回执行结果。下面简单分析一下 Command 的处理过程。
二、Agent Command 类型
- REGISTRATION_COMMAND：注册指令，当 Server 发现 节点未注册、节点当前状态为 HEARTBEAT_LOST、Agent 上传的主机状态 Server 处理失败的时候，会要求 Agent 重试进行注册。
- STATUS_COMMAND：汇报状态指令，Server 端有个定时任务 HeartbeatMonitor 默认1分钟执行一次，要求 Agent 汇报当前的组件状态、当前使用的配置版本等信息。
- EXECUTION_COMMAND：执行任务指令，当我们操作服务/组件的时候，比如：安装、启动、停止、更新配置等，就会发送这个指令。
- CANCEL_COMMAND：取消任务指令，中断一个操作。
- ALERT_DEFINITION_COMMAND：更新 Alert 定义指令，当我们修改了 Alert 信息、增删组件、删节点的时候，会发送这个指令。
- ALERT_EXECUTION_COMMAND：立即执行一个 Alert。
上面这些指令，除了 REGISTRATION_COMMAND，其他指令都需要先添加到 ActionQueue 中，Server 处理心跳逻辑时，如果发现 Agent 需要重新注册，会立即生成 REGISTRATION_COMMAND，要求 Agent 重新注册。
下面着重介绍一下 EXECUTION_COMMAND，可以看出来这个指令使用频率最高、最重要，处理逻辑也是最复杂的，理解了这个指令，其他指令的处理逻辑大同小异。
三、EXECUTION_COMMAND 处理流程
时机：用户触发了一个服务/组件的操作
服务端处理逻辑：
(1) 计算依赖，生成 Command，并保存到数据库
(2) 定期从数据库加载 Command，并添加到 ActionQueue
(3) 心跳逻辑：
· 把 ActionQueue 中的所有 Command 下发给 Agent
· 根据 Agent 的汇报，处理 Command 执行结果
1、计算依赖
如下图所示：
- 一个 Request 包含多个 Stage
- 一个 Stage 包含多个 Task
- 一个 Task 对应一条 Command
需要注意的是 Stage 之间有依赖关系，必须前一个 Stage 运行完，才能开始下一个 Stage；而多个 Task 可以并行执行。
Stage之间的依赖关系是使用有向无环图（DAG）计算出来的，下面简单介绍一下DAG：
- 节点：要执行的任务
- 有向边：依赖关系，A 到 B 的箭头，代表 B 依赖 A
- 无环：指的是没有循环依赖
举一个启动 HDFS 的例子：
在 role_command_order.json 文件中定义依赖关系： "DATANODE-START" : ["NAMENODE-START"]
生成 Command 并保存到数据库
表关系如下图：
2、定期从数据库中载入 Command 添加到 ActionQueue
这段逻辑在 ActionScheduler 类中，总结一下：
(1) 处理被取消的 Request
- 未下发的 Command，服务端直接改状态
- 已下发的 Command，生成 CANCEL_COMMAND
(2) 从数据库载入 Command 并添加到 ActionQueue
- 任务是否需要独占运行
- 同一个 Request，只能有一个 Stage 运行
- 超时逻辑
- 重试逻辑
- 前一个 Stage 运行失败，后边 Stage 直接取消
- 满足条件的 Command 添加到 ActionQueue