标签：
PacificA是微软的在基于log的分布式存储系统中的复制技术。
由于配置管理器维护着当前配置的真实情况，因此主节点不必保持不变。
这是因为配置的本地视图在不同服务器上是不必同步的。
特别是，我们必须避免这样的情况，一个老主节点和一个新主节点都在同一时间处理查询-老主节点可能没有意识到一个重配置信息已经被新主节点创建，并且已将它从配置中移除。由于新主节点可以处理新的更新，老主节点可能还在处理过期状态的查询，因此这样就违反了强一致性。
我们的方案是使用租约。通过周期性发送标灯的方式，主节点从每一个从节点那里请求一个租约，在发送标灯后等待确认。
如果从最后一个确认标灯发送的时间开始，一个指定的租约期限已过，主节点就认为租约过期。
当从节点上的任何租约过期时，主节点不再认为自己是一个主节点，并且停止所有查询或更新处理。
这种情况下，主节点会联系配置管理器从当前配置中移除从节点。只要发送者仍然保留主节点在当前配置中，从节点就认为标灯有效。
如果从主节点收到最后一个标灯开始的宽限周期已过，从节点认为对主节点的租约已过期，并将联系配置管理器去移除当前主节点，并把自己变成一个新主节点。
假设没有时钟偏差，只要宽限周期相同于或者大于租约周期，那么主节点上的租约会在从节点上处理之前被裁定为过期。
从节点会先假设配置发生改变，如果仅且如果它的租约对老主节点过期时，从节点会尝试扮演主节点的角色。
因此在新主节点被确定前，老主节点就已经被重新分配，于是主节点依旧保持不变。
我们使用租约机制作为失效检测机制。类似的失败检测机制被用于其他系统当中，如GFS，Boxwood和Bigtable/Chubby。
这里的关键的不同点是在这些系统当中租约是从中心实体获取的。而在我们的情景里，用于失效检测的监控总是处于两个服务器之间，由于数据处理在彼此之间已经存在：当处理更新的时候主节点与从节点们通讯；标灯与确认消息同样也是介于主节点与从节点之间。以这种方式，失效检测能够准确的捕获用于复制的通信通道的状态。
当通信通道繁忙的时候，数据处理消息也可以自行处理就像标灯与确认消息一样。 只有在通信通道空闲的时候，实际的标灯与确认消息才会被发送，从而可以最小化失败检测的开销。进一步来讲，在中心化的实现当中要考虑负载消除与对中心实体的依赖。负载是很明显的，因为标灯与确认消息总是定期的在系统中的中心实体和每一个服务器间交换；交换的时间间隔必须相当小，才能保证快速的失效检测。在中心化方案中，中心实体的不可用（如由于网络分区）会导致整个系统的不可用，因为当中心实体丢失租约信息时，所有的主节点不得不进行重新分配。
PacificA中的租约与失效检测解读-Kafka中用于Leader选举的策略
标签：
原文地址：http://www.cnblogs.com/moonz-wu/p/4773316.html
