容错

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