分布式系统

参考资料

• 略

Raft

Raft 基本概念

• Leader：负责处理客户端请求，管理日志复制和提交
• Follower：被动接受 Leader 的指令，处理日志复制和提交
• Candidate：在选举过程中，Follower 可能会变成 Candidate
• 本地状态机：每个节点维护一个本地状态机，应用已提交的日志条目来更新状态

Raft 读写

• 写：客户端发送写请求到 Leader，Leader 将请求作为日志条目追加到日志中，并将日志条目复制到 Followers。当大多数节点确认日志条目后，Leader 将其提交并应用到状态机
• 读：客户端发送读请求到 Leader，Leader 可以直接从本地状态机读取数据并返回给客户端，或者通过日志复制机制确保读请求在最新的状态下被处理
  • 只读 Leader, 需要保证 Leader 不是过时的，通常通过心跳机制和选举过程来确保
    • 写一条空日志条目，确保 Leader 的日志是最新的
  • 想让 Follower 处理读请求，必须使用租约机制
    • Follower 的 commitIndex 不落后于 readindex
    • 租约有效

Raft 强一致性

• 只写 Leader
• 新的 Leader 必须包含所有已提交的日志条目 (请求投票时带上 Term 与 Index)
• Leader 死掉后, 会进行选举
  • 每个 Follower 的超时器随机设置，避免同时发起选举
  • Candidate 收到大多数节点的投票后成为新的 Leader
  • 脑裂, 参考 Term 决定 Leader 的合法性

其他

• 快照加日志
• 只能提交当前 Term 的日志
• 每次只增加或删除一个节点

分布式协调

CAP

• 分布式系统中, 一致性 (C), 可用性 (A), 分区容错性 (P) 三者不能同时满足, 只能满足其中的两个

高可用

• 往往通过冗余 + 故障转移来实现高可用

延时与吞吐量

• 延时: 系统处理请求的时间, 不可能为 0
• 吞吐量: 系统在单位时间内处理请求的数量, 可能为无限
• 单线程时, 延时 = 处理时间, 吞吐量 = 1 / 处理时间