开发者学堂课程【分布式系统开发调度技术：容错机制和规模挑战】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/367/detail/4370
容错机制和规模挑战
内容介绍：
一、容错机制
1.任务调度的故障恢复
2.资源调度的 failover
二、规模挑战
1.增量的消息通讯
2.异步持续多线程
一、容错机制
在一个大规模的分布式系统当中，故障是常见的
1>来自硬件的故障
1.磁盘：一般有4%的年损坏率
2.主板
3.内存条
等硬件都存在一些异常情况。
2>来自软件的故障
1.存在 BUG
2.内存访问越界
3.进程 crush
4.整机重启
所以一个稳健的分布式系统，应该能够处理这种硬件或软件的故障。角色在恢复时，通常考虑以下四个方面：
1.正在运行的任务不应该被中断
2.对用户是透明的
3.自动故障恢复
4.系统在恢复时依然保持可用性，用户的体验不受影响
1.任务调度的故障恢复
任务调度主要有 app master 和 app worker，这两种角色都可能发生 failover。
1>app worker 发生 failover
instance可以通过重试的机制来挑选另一个 app worker 完成这个 instance 任务。
2>app master 发生 failover
app master 若发生过重启，它的状态首先可以从 walker 往上报的状态里恢复出之前的调度结果，还可以恢复出之前在哪些节点上分配了哪些 instance，而具体到每一个instance在处理数据时所在位置的进度信息，也可被 app master 进行持久化，称为打快照 Checkpoint,它会定期的存在持久化存储上，当 app master 进程发生 failover 时，能够从持久化存储中读取这个快照，从而恢复之前的 instance完成情况，通过这样的机制，整个任务在执行期间，任何角色发生 failover 都可以不影响整个作业的运行。
2.资源调度的 failover
参与资源调度的主要有 Fuxi master，app master 以Tubo 几个角色。
Fuxi Master 作为中控节点，恢复所需要的信息是非常大的，信息量很多，在工程实践时考虑一些细节，将这个角色所缺的状态分成两种，一种是可以从状态里恢复的，称之为 soft state（软状态）；一种是无法从其他的状态里恢复的，称之为hard state(硬状态)，例如用户提交的作业配置信息。
对于硬状态，会将它存储在持久化存储上，类似于前面打快照机制，这些状态变化的是不平凡的。
而 soft state，恢复时会通过命令的方式要求 Tubo 或 app master 将进程死之前的状态再发送一份，从而帮助 Fuxi master 恢复出在进程 crash 之前的状态，
如：
机器列表
每个 app master 的资源请求等信息。
具体的过程如下图，中间的 Fuxi Master 如进程发生重启要恢复之前的状态，一方面可以从每个 Tubo 上报的状态里恢复出之前给每个机器上分配的资源；另外一方面从每个 app master 上报的状态里恢复出在进程挂之前每个应用所产生的资源请求，从消息状态里就可以恢复出 soft state。
另外一方面，通过读取存储在持久化介质上的 checkpoint 可恢复出进程在挂之前用户提交上的所有作业的配置情况。
以上是关于资源调度和任务调度发生硬件或软件故障造成进程重启之后，如何恢复出之前的状态，称为容错的各种机制。
二、规模挑战
分布式系统设计目标之一是横向扩展，Scale-out。一为增量的消息通讯，另一为异步持续多线程的问题。主要包括多线程异步如何优化及增量资源调度。
1. 异步持续多线程
如下图一个作业所对应的 app master，实际上有两种通讯，一个和 FuxiMaste 进行资源的申请、释放等交互，另外一方面，需要和为数众多的 Tubo 进行通讯来起或停止 app worker。
在分布式计算当中，通常是通过RPC（远程调用）机制实现两个异地的进程进行通讯。假若在 app master 里将 FuxiMaster 和众多的 Tubo 对于 RPC 消息的处理，全部放在一个线程，虽然使用了线程池增加并发度，但由于 FuxiMaster 只有一个，而 Tubo 通常有5000个
规模之多，所以大量的RPC消息若拥挤在一个线程池里，则 FuxiMaster 重要的消息，可能会被处理的几率会大大降低，甚至为1/5000的概率。
因此为了避免 Fuximaster 该类重要消息得不到处理，采取的手段是在 app master里单独给 FuxiMaster 分配一个线程池来处理来自 FuxiMaster 的消息，而其他为数众多的Tubo的消息则用另外一个线程池来处理，这样可以避免在分布式系统中常见的堆头阻塞的问题。
等我这种手段，FuxiMaster 和 app master 间关于资源的申请和释放这一协议的通讯变得非常通畅。
在一个5000台规模的集群中 FuxiMaster 所完成的事情及处理的逻辑是非常复杂的，一方面需处理每个 app master 所发的资源请求，有时达上万个，另一方面需监控5000个Tubo 节点的健康状态，因此如何提高 FuxiMaster 这一个节点的处理速度，如何简化消息通讯的协议，是提高规模扩展性的非常重要的技术手段。
2.增量资源调度
如下图，当一个 app master 向 FuxiMaste 发起资源请求“需要1000份资源”，FuxiMaster 完成调度后，会部分的给一部分200份资源，app master 则再次发起请求“需要800个”，FuxiMaster 给150个，通过这样一来一往的消息通讯，1000个全部满足可能需达三个或四个交互来回，链度很长，这是常规的主从架构设计里面临的问题。在阿里云的实践里，采取了一种新的方式，增量的，在起初时app master 发起请求“需要1000分资源”，消息发送到 FuxiMaster 会被记录下来，FuxiMaster 了解 app master 最初的资源请求状况，当部分资源释放后，FuxiMaster将资源调度给 app master，则会给 app master 发送请求“可以分配200个资源”。
之后由于 FuxiMaster 已经记录了 app master 的资源请求，当有更多新的资源释放出时，例如又有新的150个资源出来后，这时 FuxiMaster 只需发送一次请求告知app master“又新分配150个资源”，从而省去中间 app master 再次提起请求，避免了冗余的交互过程，通过增量的通讯调度的协议之后，网络中所发起的RPC消息将会大大减少，从而有利于提高整体集训的规模。
