驱动

时钟可以用来标示系统中时间的发生次序，如果系统的所有进程的时钟都是同步的，那么系统中的所有进程就能达成关于事件次序的共识。然而，现实世界中时钟无法绝对同步，即使使用 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 存储系统的最后一块拼图。

背景

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

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

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