容错
framework-->master-->(slave->executor->task)
framework宕机(调度器)
a. framework挂掉不会影响已有任务的执行
b. 若master实现故障恢复功能, 会重新向master注册并获取所有任务的状态信息master宕机
a. mesos使用zookeeper作为选举服务
b. master使用选举leader保证高可用, 当leader挂掉, 会根据选举算法选出新的leader, 所有framework和slave会向重新新的master进行注册, 而不影响以后框架调度器、slave、执行器和任务不受影响slave宕机:
a. master发送slave宕机事件给framework, framewrok决定是否调度任务到健康的slave上
b. slave恢复后，会向master重新注册slave进程挂掉
a. 不会影响执行器, 待slave重启后会恢复任务, 若执行器检查slave恢复时间超过限制则自杀执行器或者任务挂掉
a. 执行器挂掉或者任务挂掉，slave会给master反馈任务执行失败, framework会接收到master发回的事件, 决定任务重新调度
故障
mesos集群通过与zookeeper的连接是否超时判断组件的故障状态, 可将mesos组件分为竞争者和观察者, 框架和slave是观察者, master即使观察者又是竞争者, 默认配置为10s
- slave与zookeeper连接超时, slave不会接收任何master发送的任务消息, 当连接恢复slave会重新接收和处理master发送的信息, 在过程中master无论是否重新选举
- framewrok调度器驱动和zookeeper连接超时, 则调度器驱动会通知调度器, 由调度器决定
- master与zookeeper连接超时
a. master为leader, 则自杀, 其他守护模式的master进行重新选举, 可以用daemon的方式将master进行守护
b. master为守护模式, 则等待 - master和slave连接超时, master会将slave设置为未激活状态, 设置任务LOST, 将任务状态返回给框架调度器， 为激活状态的slave不会像master重新注册并且会被之后的消息要求主动关闭可以用daemon的方式将slave进行守护)
问题：
- slave在master故障时出错, 新选举的master并不值得slave和运行在slave上任务的存在, 导致framework不能正常知道任务的状态信息(框架认为任务正常，而master不清楚任务在历史上的存在)
- master在slave故障时出错, slave在master leader选举成功后恢复, 此时新的master并不值得slave的存在允许其以一个新的身份注册, 导致framework和master信息不一致(framework并不知道slave上已经运行的任务)
mesos使用registry持久化已经注册的slave信息, 当slave在注册、重新注册和删除时会查看和修改registry数据，目前实现为内存(zookeeper)、LevelDB、Replicatedlog三种方式
若slave的信息不存在于registery中时不允许器重新注册 c
