PacificA中的租约与失效检测解读

PacificA是微软的在基于log的分布式存储系统中的复制技术。

因为配置管理器维护着当前配置的真实状况，所以主节点没必要保持不变。

这是由于配置的本地视图在不一样服务器上是没必要同步的。

特别是，咱们必须避免这样的状况，一个老主节点和一个新主节点都在同一时间处理查询-老主节点可能没有意识到一个重配置信息已经被新主节点建立，而且已将它从配置中移除。因为新主节点能够处理新的更新，老主节点可能还在处理过时状态的查询，所以这样就违反了强一致性。 

咱们的方案是使用租约。经过周期性发送标灯的方式，主节点从每个从节点那里请求一个租约，在发送标灯后等待确认。

若是从最后一个确认标灯发送的时间开始，一个指定的租约期限已过，主节点就认为租约过时。

当从节点上的任何租约过时时，主节点再也不认为本身是一个主节点，而且中止全部查询或更新处理。

这种状况下，主节点会联系配置管理器从当前配置中移除从节点。只要发送者仍然保留主节点在当前配置中，从节点就认为标灯有效。

若是从主节点收到最后一个标灯开始的宽限周期已过，从节点认为对主节点的租约已过时，并将联系配置管理器去移除当前主节点，并把本身变成一个新主节点。

假设没有时钟误差，只要宽限周期相同于或者大于租约周期，那么主节点上的租约会在从节点上处理以前被裁定为过时。

从节点会先假设配置发生改变，若是仅且若是它的租约对老主节点过时时，从节点会尝试扮演主节点的角色。

所以在新主节点被肯定前，老主节点就已经被从新分配，因而主节点依旧保持不变。 

咱们使用租约机制做为失效检测机制。 相似的失败检测机制被用于其余系统当中，如GFS，Boxwood和Bigtable/Chubby。

这里的关键的不一样点是在这些系统当中租约是从中心实体获取的。 而在咱们的情景里，用于失效检测的监控老是处于两个服务器之间，因为数据处理在彼此之间已经存在：当处理更新的时候主节点与从节点们通信；标灯与确认消息一样也是介于主节点与从节点之间。 以这种方式，失效检测可以准确的捕获用于复制的通讯通道的状态。

当通讯通道繁忙的时候，数据处理消息也能够自行处理就像标灯与确认消息同样。 只有在通讯通道空闲的时候， 实际的标灯与确认消息才会被发送，从而能够最小化失败检测的开销。 进一步来说，在中心化的实现当中要考虑负载消除与对中心实体的依赖。负载是很明显的，由于标灯与确认消息老是按期的在系统中的中心实体和每个服务器间交换；交换的时间间隔必须至关小，才能保证快速的失效检测。 在中心化方案中，中心实体的不可用（如因为网络分区）会致使整个系统的不可用，由于当中心实体丢失租约信息时，全部的主节点不得不进行从新分配。