背景

hypervisor 控制整个 VM 的执行环境，因此可能高效地实现可容错的虚拟机系统。论文在 WMware vShpere 4.0 上实现了一个可用于生产环境的可容错虚拟机，称为 VMware FT。

设计

论文聚焦于如何实现一个可用与生产环境的容错虚拟机，更多聚焦于实现容错的策略（协议），底层使用的机制依赖于 VMware 的其他技术。虚拟机复制使用 VMware VMotion，这个技术原本用于迁移 VMware 虚拟机，VMware FT 稍作修改，用于复制虚拟机和重启虚拟机。使用 VMware 的 deterministic replay 技术记录主虚拟机的执行并确保副本的执行于主虚拟机相同。

驱动

时钟可以用来标示系统中时间的发生次序，如果系统的所有进程的时钟都是同步的，那么系统中的所有进程就能达成关于事件次序的共识。然而，现实世界中时钟无法绝对同步，即使使用 NTP 等时钟同步技术，不同计算机间的时钟也会存在误差（NTP 误差为数十毫秒）。

• 为什么 Leader 要提交之前任期的日志？

  因为 Leader 复制先前任期的日志时，不将日志的任期修改为当前任期。因此会出现先前任期的日志被复制到多数派，但仍未提交的情况。只有当前任期的日志被复制到多数派才算提交，Log Matching Property 确保了当前日志被提交时所有之前的日志均被提交。

• 节点的currentTerm是否一定和本地 log 中最新的 entry 的任期相同？

  不一定。currentTerm在选举时递增，会存在currentTerm比 log 的 term 更新的情况。

背景

Zookeeper 是一个简单且高性能的分布式协调系统，它自身不实现任何用户所需的协调功能，但提供了一个内核（一组 API）供用户实现自己的分布式协调原语。用户通常使用 zookeeper 实现以下功能：

• 可容错的元数据存储
• 服务发现
• 分布式锁
• 组成员管理
• 领导者选举

zookeeper 使得分布式系统的协调变成了一个独立的组件，从而解耦了分布式系统内的协调和其他组件，使得设计可容错的分布式系统更加容易。

设计

Redis Cluster 被设计来覆盖单机版本的用例，是将单机 Redis 实例带入分布式系统的方案，而不是将 Redis 变成类似 MongoDB 的分布式数据库。

性能是 Redis Cluster 的第一目标，在实现高性能和线性拓展的前提下实现弱但是合理的数据安全性和可用性。

背景

Facebook 的 BLOB（Binary Large OBject）工作负载有以下特征：

• Write Once Read Many
• 冷热分区
• 不可变数据

Finding a needle in haystack Facebook’s photo storage 的目标是高 IOPS，但存储成本高。面对冷热分区的工作负载，Facebook 设计了暖存储系统 f4，专为第存储成本和高容错设计，填补 Facebook BLOB 存储系统的最后一块拼图。