浅谈分布式一致性协议 ｜ 青训营笔记

这是我参与「第四届青训营 」笔记创作活动的第12天

分布式系统

分布式系统面临的挑战

• 数据规模越来越大
• 服务的可用性要求越来越高
• 快速迭代的业务要求系统足够易用

理想中的分布式系统

• 高性能：可拓展、低时延、高吞
• 正确：一致性、易于理解
• 可靠：容错、高可用

什么是一致性

• 对于我们的KV

  • 像操作一台机器一样
    • 要读到最近写入的值

• 一致性是一种模型（或语义）

  • 来约定一个分布式系统如何向外界（应用）提供服务
  • KV中常见的致性模型
    • 最终一致性：读取可能暂时读不到但是总会读到
    • 线性一致性：最严格，线性执行

• 一致性的分类

  • 经常与应用本身有关

• Linearizability是最理想的

复制协议

• 当主副本失效时，为了使得算法简单
  • 可以人肉切换，只要足够快
    • 还是可以保证较高的可用性
• 如何保证主副本是真的失效了呢
  • 在切换的过程中，主副本又开始接收client端的请求
  • 两个主副本显然是不正确的，log会被覆盖写掉
  • 我们希望算法能在这种场景下仍然保持正确
• 假如增加到三个节点呢
  • 每次都等其他节点操落盘性能较差
  • 能不能允许少数节点挂了的情况下，仍然可以工作
    • falut-tolerance

共识算法

• 共识协议不等于一致性
  • 应用层面不同的一致性，都可以用共识协议来实现
    • 比如可以故意返回旧的值
  • 简单的复制协议也可以提供线性一致性
• 一般讨论共识协议时提到的一致性，都指线性一致性
  • 因为弱一致性往往可以使用相对简单的复制算法实现

Raft

Raft角色

Raft Term

• 每个Leader服务于一个term
• 每个term至多只有一个leader
• 每个节点存储当前的term
• 每个节点term从一开始，只增不减
• 所有rpc的request reponse都携带term
• 只commit本term内的log

Raft主节点失效

• Leader定期的发送AppendEntries RPCs给其余所有节点
• 如果Follower有一段时间没有收到Leader的AppendEntries,则转换身份成为 Candidate
• Candidate自增自己的term,同时使用RequestVote RPCs向剩余节点请求投票
  • rat在检查是否可以投票时，会检查log是否outdated,至少不比本身l旧才会 投给对应的Candidate
• 如果多数派节点投给它，则成为该term的leader

共识算法的未来

• Raft Paxos相互移植
  • Rat有很多成熟的实现
  • 研究主要关注在Paxos上
  • 如何关联两种算法
    • On the Parallels between Paxos and Raft,and how to Port Optimizations
    • Paxos vs Raft Have we reached consensus on distributed consensus
• 共识算法作为一个系统
  • 多数分布式系统都选择共识算法作为底座
  • 不同一致性协议有不同的特性
  • Virtual consensus in delos
    • 对外暴露一致性的LOG作为借口
    • 内部对于LOG可以选择不同的实现