为什么 Leader 要提交之前任期的日志？ 因为 Leader 复制先前任期的日志时，不将日志的任期修改为当前任期。因此会出现先前任期的日志被复制到多数派，但仍未提交的情况。只有当前任期的日志被复制到多数派才算提交，Log Matching Property 确保了当前日志被提交时所有之前的日志均被提交。 节点的currentTerm是否一定和本地 log 中最新的 entry 的任期相同？ 不一定。currentTerm在选举时递增，会存在

背景 Zookeeper 是一个简单且高性能的分布式协调系统，它自身不实现任何用户所需的协调功能，但提供了一个内核（一组 API）供用户实现自己的分布式协调原语。用户通常使用 zookeeper 实现以下功能： 可容错的元数据存储 服务发现 分布式锁 组成员管理 领导者选举 zookeeper 使得分布式系统的协调变成了一个独立的组件，从而解耦了分布式系统内的协调和其他组件，使得设计可容错的分布式系统更加容易。 会话 ZooKeeper 使用会话标示

设计 Redis Cluster 被设计来覆盖单机版本的用例，是将单机 Redis 实例带入分布式系统的方案，而不是将 Redis 变成类似 MongoDB 的分布式数据库。 性能是 Redis Cluster 的第一目标，在实现高性能和线性拓展的前提下实现弱但是合理的数据安全性和可用性。 架构 [!NOTE] 图中的 gossip 虚线表示： 每个节点都彼此通过 gossip 相联。 领导者选举时，每个 group 的候选人都从其他 group 的 master 获取投票。 每个节点都有一个全局唯一且不变的 Node ID，Node ID 是节点的唯一

背景 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 存储系统主要要思考三个问题： 如何组合热存储 haystack 和暖存储 f4 为一个 BLOB 存储系统？ 如何实现低存储成本？

背景 Ceph 是一个高性能、可靠的、可拓展的分布式文件系统。Ceph 最主要的目标是可拓展性，即如何使得文件系统支持任意多的数据量。 Ceph 面临以下难题： 如何高效地管理元数据？ 如何确保一致性？ 如何服务热点？ 如何服务动态的工作负载？ 如何高效地管理数据？ 数据容错 复制 设计 元数据管理是实现高性能分布式文件系统的一大难点，元数据操作甚至占典型工作负载的 50。由于元数据存在较多的依赖，

有序链表无法在$O(logN)$时间复杂度内搜索的根源在于：链表不支持随机访问。既然不支持随机访问，可以通过增大步长降低搜索次数。 每个隔 2 个节点，该节点同时指向它 2 个位置后的节点。这样，搜索只需要$N/2+1$步。 继续增大步长，在 b 的基础上，每隔 3 个节点，该节点同时指向它后面 3 个位置后的节点。这样，搜索只需要$N/3+2$步。 不断增大步长，每隔 i 个节点，该节