一致性

发布于 2015-12-05 11:07:11 | 488 次阅读 | 评论: 0 | 来源: 网络整理

无可否认，在Mesos的计算框架是分布式系统。

分布式系统必须对失败和分隔（两个系统内部无法进行区分）进行处理。

实际上，计算框架是什么意思呢？Mesos使用执行起来像信息传递的编程模式，无论那个信息只被传递最多一次。 (包含任务状态更新是例外情况，大部分信息传递最少用来至少一次确认)。消息在管理器和计算框架之间通信，当存在故障时，容易发生丢弃。

当这些不可靠的消息丢弃时，会在计算框架和Mesos发生不一致的状态。　　

列举一个简单的例子，需要给计算框架发送决定启动任务。有许多失败方式可以导致这些任务的丢失。举例：　　

• 计算框架在意图持续启动任务后发生失败，但启动的任务已经发送了信息。
• 管理器在接收到信息之前发生失败。
• 管理器在接收到信息之后发生失败，但在这之前已经发送给节点信息。

在上面这些情况下，计算框架认为任务在执行中，但是任务并不知道如何给Mesos。为了应对这种局面，任务状态必须随时发现错误协调计算框架和Mesos。　　

发现错误

发现错误是Mesos的责任（调度器驱动/管理器）来确保可以通知无链接的计算框架，随后（再次）登记错误所发生的事情。在这点上，调度器需要前去对任务状态进行调解。

任务一致性

Mesos提供了两种保持一致的方式：

• “显式” 一致性: 如果可能，调度器发送那些未结束的任务并且管理器对每个任务进行响应。　　
• “隐式” 一致性: 调度器发送一个空的任务列表，管理器响应所有现在已知非终结的任务的最新状态。　　

在计算框架发生错误后，以显式方式使任务保持一致。　　

上面这种方式是由于调度器驱动不能持续掌握任何任务信息。在未来的版本，调度器驱动(或者mesos开发库)可以在代表计算框架下无缝覆盖运行任务一致性。

因此，现在在计算框架调度器中，让我们来看看如何实现一件必须要一致的任务状态。

API

计算框架会给管理器发送TaskStatus信息的列表：

// 允许计算框架去查询非终结任务的状态。如果可能的话，在'statuses'管理器
// 返回为每个任务最新状态返回的原因。当TASK_LOST更新，任务不再知道结果。
// 如果statuses为空，管理器将会给当前每个已知的任务发送最新的状态。
message Reconcile {
  repeated TaskStatus statuses = 1; // 应当仅仅非终结。
}

当前，管理器仅仅对TaskStatus检查两项数据列：

• TaskID: 这个是必备的。
• SlaveID: 可选项，在存在状态间转换的节点时，会导致更快的一致。

算法

这个显式一致性技术保持所有未结束任务的一致，直到每个任务接收到更新，使用指数退避算法再次尝试剩下未取得一致的任务。重试是必要的，管理器可能不能对特殊任务进行应答。例如，在管理器失效时候，管理器为了重建它已知的任务必须重新注册所有的节点(重建过程会花费大型集群几分钟的时间，并在管理器通过--slave_reregister_timeout标记进行上限限制)。

步骤:

1. 让 start = now()
2. 让 remaining = { T in tasks | T is non-terminal }
3. 执行一致性: reconcile(remaining)
4. 等待状态更新信息到达(使用短指数退避算法)。对于每个更新，注意到达的时间
5. 让 remaining = { T ϵ remaining | T.last_update_arrival() < start }
6. 如果 remaining 不为空,则跳转到步骤3。

一致性算法必须在每次(再次)注册之后。

隐性一致性(通过一个为空的列表)应当周期性执行，在计算框架中作为防御数据丢失事件的发生。除非在管理以严格注册方式使用，这种方法可能使那些进入LOST状态的任务复活(没有严格注册，管理器无无法给任务施加故障移除)。当遇到一个未知任务时，调度器应当把任务关闭或者恢复。

注意:

• 当等待更新到来时，使用短指数退避算法。这个算法在备份驱动或者管理器时避免滚雪球效应。
• 隐性一致性有益于确定仅在同一时间只进行一次一致操作，避免面对大量重新注册的情况发生滚雪球效应。如果要启动另一个一致操作，那之前的一致性计算程序应当停止运行。

要约一致性

在失败发生后，要约会自动保持一致:

• 要约不会超过管理器的声明周期。
• 如果发生链接中断，要约不在有效。
• 要约在每次计算框架(再次)注册发生撤销和新建。