• 2021-07-30

    为什么极少有开源的Paxos库?

    Views: 290 | No Comments

    你是不是也很奇怪, Paxos 既然被称为唯一的共识算法(分布式一致性算法), 是分布式系统的基石, 那么为什么极少看到开源的 Paxos 库呢? 反观 Raft, 有 etcd 开源的 go 语言写的库, 有 PingCap(tidb)开源的 Rust 语言写的, 还有百度, 阿里等等公司开源的各种语言的库. 既然 Paxos 那么牛逼, 为什么江湖中只有它的传说, 却从来没有人见过它的身影呢?

    原因很简单, Paxos(准确的说是 Basic Paxos) 是共识算法, 用于对一个实例的状态形成共识, 这个用途和工程上的一致性协议基本是金属铁块和汽车的关系. 工程师对 Paxos 最大的疑问经常是:

    • 什么是实例? 一整个 database 是一个实例吗? 一个 key 是实例吗?
    • 共识是什么? 是一个 key 对应的 value 吗? 形成共识之后就不能更改? 有什么用?

    所以, Basic Paxos 不是问题的解决之道. 有所谓的 Multi Paxos, Paxos 的论文中对这个模型(有人认为就是复制状态机)的定义和讨论非常不完善, 一千个人有一千种看法, 而且大多还是错的.

    Raft 提出了工程上的分布式一致性协议的核心本质: 选主和日志复制状态机.

    管你什么 Multi Paxos, Fast-Paxos, X-Paxos, ABC-Paxos, 通通都是日志复制状态机. 管你成员显式选主还是客户端认主, 通通都是选主.

    你说 Paxos 不需要 Leader, 那还不是要求客户端根据 Hash 算法认定一个节点作为 Leader? 你说你的日志序列支持空洞, 还支持乱序 Apply 日志(执行指令), 但两条指令执行的顺序不同必然导致结果不同, 结果(状态)都不相同, 你还谈什么一致性?

    做来做去, 还不是 Raft 所总结的那一套方法吗? - 就是选主和日志复制状态机!

    所以, 为什么没人开源 Paxos 库? 因为工程上要做的工作, Paxos 只占 1% 的工作量, 你把 1% 的微小工作包装成一个库? 有啥卵用? 没有人会用的, 因为这个库什么功能也没有, 什么问题也没解决(准确地说只解决了 1%).

    还要什么 Paxos 开源库? 要的是选主, 日志复制状态机, 成员变更, 就是 Raft 那个样子, 即使你心里面极度排斥 Raft, 但最终你还是会把一个 Paxos 库实现成 Raft 的样子.

    Posted by ideawu at 2021-07-30 00:24:42 Tags: ,
  • 2021-07-25

    Raft ReadIndex 有什么神奇之处?

    Views: 375 | No Comments

    其实, 工程上的一致性读, 本质是操作的先后顺序. 只要让读操作在某一个节点上发生的顺序, 在我们预想的那个写操作之后, 这时只依赖该节点, 就能保证一次正确的一致性读. 例如, 假设我们知道某次写操作的序号是 idx, 对应某条编号为 idx 的日志, 只要我们等某个节点 apply 了这条日志, 然后直接读状态机就可以了, 就能满足强一致性的定义.

    但是, 虽然可以要求客户端请求读操作时带上它所依赖的那次写操作的编号, 但工程上并不合理, 所以, 只能由集群节点自己找到那次写操作的编号.

    收到读请求的节点, 向其它节点发送一个请求, 询问最新的日志编号是多少, 如果收到全部节点的回应, 那么自然就知道了. 要求全部节点回应, 不能容忍少数节点宕机, 这种方案还需要优化. 其实, 超过半数回应就可以了.

    简单的说, 就是任何一个 Raft 成员, 无论 Leader 还是 Follower, 收到读请求时, 通过某些手段获知当前集群最大的 commit index, 然后等待自己 apply 等于或者超过这个 commit index 之后, 直接读本地状态机.

    大多数人可能并不知道, 即使是 Leader, 直接读本地状态机, 也是有可能违反"强一致性"的定义的. 因为, 除非站在上帝视角, 否则, 一个 Leader 节点只能是"自认为自己是 Leader", 既然是自认为是, 就有可能错认.

    所以, 如果读本地状态机, 就必须停止等待, 确保状态机已经 apply 了"那一条日志"之后才能读. 具体是哪一条日志? 前面说了.

    相关文章: PingCap - 线性一致性和 Raft

    Posted by ideawu at 2021-07-25 19:45:34 Tags:
  • 2021-07-17

    什么是 Paxos 的日志空洞?

    Views: 537 | No Comments

    Paxos 所谓的日志空洞, 在讨论 Paxos 和 Raft 对比时出现的频率非常高, 非常显眼. Paxos 的日志空洞是什么? "日志空洞"对线性一致性有什么影响? 我认为大多数人都对 Paxos 日志空洞有误解, 包括我之前也是.

    很多人认为 Multi Paxos 可以允许空洞, 但是 Paxos 论文提到:

    To guarantee that all servers execute the same sequence of state machine commands, we implement a sequence of separate instances of the Paxos consensus algorithm, the value chosen by the ith instance being the ith state machine command in the sequence.

    状态机必须严格按顺序执行(apply)命令, 所以, Multi Paxos 并不允许 apply 时出现所谓的日志空洞. 虽然会乱序 chosen(也即所谓的空洞), 但是, apply 一定是严格按顺序进行的. Apply 的时候, 如果不是严格按顺序的, 就不是日志复制状态机.

    但是, 因为必须严格按顺序执行日志序列, 所以, 即使 Multi Paxos 乱序 chosen 日志, 也不会影响外部一致性.

    Continue reading »

    Posted by ideawu at 2021-07-17 22:48:54 Tags: ,
  • 2021-07-13

    Leader based 的集群也可以100%高可用

    Views: 450 | No Comments

    很多初学者错误地认为, 像 Raft 这样的 leader based 的分布式协议不是 100% 高可用的, 因为"Raft 在选主的过程中, 不能提供服务". 初学者之所以存在这种错误认知, 完全是因为他们没有理论结合实践, 只略懂一点理论皮毛, 就胡乱引申导致的. 本文将在理论和实践结合的层面上, 分析这种错误认知.

    首先, Raft 的选举过程并没有特殊的成本, 在局域网条件下, 一般只需要 5ms 的时间. 5 毫秒对于实用的分布式集群, 是微不足道的时间长度, 因为客户端对时间长度的认知是百毫秒级别的, 只要客户端在 5 毫秒之后重试[可靠通信三原则], 或者服务器先 Hold 住请求, 过 5 毫秒之后再处理, 对于客户端来说, 完全没有感受到服务不可用, 因此, 服务是 100% 高可用.

    我认为, leader based 的集群, 最大的问题在于"何时发起选举?". 也就是, 如何能快速地发现当前集群失去了有效的 leader.

    客户端可能发现集群无主, 但是, 我们不会把这个权限赋予客户端, 因为在 CS 理论中, 客户端是不可信的. 所以, 只能交由集群成员去发现集群是否需要发起选举.

    Continue reading »

    Posted by ideawu at 2021-07-13 21:57:52 Tags:
  • 2021-06-29

    分布式数据库系统的容错处理 – 100% 成功率, 超时和性能

    Views: 754 | No Comments

    之前写过一篇文章, 介绍"可靠通信三原则". 对于一个分布式数据库, 如果想实现 100% 高可用(也即客户端的请求永远不会返回失败), 同样可以用可靠通信三原则中的重试理论和去重理论来解决. 但在实践上, 需要在成功率, 耗时(速度和性能)各方面进行取舍. 本文分享实际经验, 介绍什么样的选择是普适的, 各位可以参考.

    客户端访问数据库服务器, 发起大量的请求, 绝对不可能做到每一个请求都是成功的. 因为网络原因, 请求可能失败. 因为服务器内部处理冲突, 或者分布式节点间协调冲突, 都可能导致请求失败.

    所谓容错处理, 就是在遇到错误的时候进行重试. 因为错误必然发生, 只有重试才能消除错误的影响, 就好像 IP 层必然会丢包, 但 TCP 协议通过重传达到某种程度的可靠传输.

    某些实现了 Basic Paxos + 日志复制状态机模型的系统, 因为所谓的"Leaderless", 会产生大量冲突. 即使是使用 Raft, 在某些情况下意外发生选举, 也会导致请求冲突.

    Continue reading »

    Posted by ideawu at 2021-06-29 22:16:55 Tags: ,
  • 2021-06-27

    分布式数据库如何做到异地多活?

    Views: 1384 | 2 Comments

    前段时间写过一篇文章"分布式数据库系统如何做到平滑缩扩容?", 讲了分布式数据库在扩容(集群服务器开机关机)过程中, 如何保证服务 100% 不中断. 那篇文章主要是从客户端的角度去考虑问题, 正如该文章所说的, 一个分布式系统, 必须服务端和客户共同协作, 才能实现服务不中断. 本文从服务端, 也即狭义理解的"数据库系统"的角度, 分析一个分布式数据库系统是如何做到 100% 高可用的.

    注意, 高可用, 异地多活, 多主(Leaderless), 这些词汇, 本质上是指同一个东西, 都是指在单一节点宕机时, 客户端可以切换(切主)到其它节点访问, 或者说, 客户端在平时可以访问任意一个节点(多主) -- 切主多主是一回事, 只要可以做到足够快速地切主, 即使表面上一个系统是有 Leader Based 的, 那么它和 Leaderless 没有区别. 阅读本文之后, 相信你能加深对这些概念的理解.

    首先说一个定理: 只有强一致性的多副本系统, 才能异地多活.

    Continue reading »

    Posted by ideawu at 2021-06-27 23:24:48 Tags: ,
|<<<1234>>>| 1/4 Pages, 20 Results.