前言

分布式确实是一个有趣的话题,只要你留心观察,分布式在生活中无处不在。

悟空哥最开始学习分布式是从一篇非常用心写的技术征文开始的,而且这篇文章获得了征文第一名,在此感谢掘金社区提供的平台。想学习的同学可以点这个文章链接:《这三年被分布式坑惨了,曝光十大坑》

前两讲主要是讲解分布式理论,涉及到了分布式的四大理论。

拜占庭将军问题:《用三国杀讲分布式算法,舒适了吧?》

BASE、CAP、ACID:《用太极拳讲分布式理论,舒服!》

从这篇开始,将会讲解分布式的八大协议/算法。本篇主要讲解 Paxos 共识算法。

本文主要内容如下:

Paxos 算法

Paxos 是分布式算法中的老大哥,可以说 Paxos 是分布式共识的代名词。最常用的分布式共识算法都是基于它改进。比如 Raft 算法(后面也会介绍)。所以学习分布式算法必须先学习 Paxos 算法。

Paxos 算法主要包含两个部分:

  • Basic Paxos 算法:多个节点之间如何就某个值达成共识。(这个值我们称作提案 Value
  • Multi-Paxos 算法:执行多个 Basic Paxos 实例,就一系列值达成共识。

Basic Paxos 算法是 Multi-Paxos 思想的核心,Multi 的意思就是多次,也就是说多执行几次 Basic Paxos 算法。所以 Basic Paxos 算法是重中之重。

三国中的 Paxos

三国中刘备集团,有两大军师:诸葛亮和庞统,都是非常厉害的人物,当他们有不同作战计划给多名武将时,如何达成一致?

角色

Paxos 中有三种角色:提议者、接受者、学习者。

让我们用更通俗的方式来讲解 Paxos 算法。让我们穿越回东汉末年,刘备集团的帐营中一同学习 Paxos 算法是怎么攻打曹操的。

刘备的帐营中人物介绍:

  • 主公一名刘备,作为请求方或客户端

  • 军师两名诸葛亮庞统,作为提议者

  • 武将三名关羽张飞赵云,作为接受者

  • 文臣两名法正马良,作为学习者

提议者(Proposer)

  • 提议一个值,用于投票表决。
  • 接入和协调,收到客户端的请求后,可以发起二阶段提交,进行共识协商。
  • 映射到上面的故事中,军师就是用来部署作战计划的。

接受者(Acceptor)

  • 对每个提议的值进行投票,并存储接受的值。

  • 投票协商和存储数据,对提议的值进行投票,并接受达成共识的值,存储保存。

  • 映射到上面的故事中,武将就是用来接受军师的作战计划。

  • 其实,集群中所有的节点都在扮演接受者的角色,参与共识协商,并接受和存储数据。

学习者(Learner)

  • 被告知投票的结果,接受达成共识的值,存储数据,

  • 不参与投票的过程,即不参与共识协商。

  • 映射到上面的故事中,就是两名文臣作为记录作战方案的备胎

接受者 or 提议者

为什么说节点可以扮演接受者,也可以扮演提议者呢?

上篇我在讲解 BASE 协议的时候,讲到二阶段提交协议。其中有一个协调者的身份,协调者既可以是接受者,也可以是提议者。

  • 作为接受者,接收客户端的消息。比如诸葛亮需要接收刘备的作战要求。
  • 作为提议者,发起二阶段提交。然后这个节点和另外其他节点作为接受者进行共识协商。比如诸葛亮要汇总最终的作战计划给刘备

如下图所示,节点 1 作为提议者和接受者,节点 2 和节点 3 作为接受者。

诸葛亮 VS 庞统

三国中有刘备集团(占据西蜀)、曹操集团(占据北边)、孙权集团(占据江南)。

诸葛亮庞统作为提议者,向三个接受者进作战计划的提案。提案中有两个属性:

  • 提案编号,每次军师进行提案,都会有个编号,这里用 n 表示。
  • 提议值,也就是作战计划,这里用 v 表示。所以提案就是 [n, v]。

诸葛亮的作战计划是从北边进攻曹操,庞统的作战计划是从南边进攻曹操,而关羽、张飞、赵云先后收到了他们的作战计划,该听谁的呢?这里就是一个共识的问题。而 Paxos 算法达成共识分两个阶段。准备(Prepare)阶段接受(Accept)阶段

准备阶段

诸葛亮和庞统作为提议者,分别向所有的接受者(关羽、张飞、赵云)发送包含作战计划编号(提案编号)的准备请求,但不包含作战计划(提案值)。

发送准备请求

  • 提议者诸葛亮先发送编号为 1 的作战计划的准备请求,庞统发送编号为 2 的作战计划的准备请求。

  • 接受者关羽(节点 X)在8 点收到来自诸葛亮发送的作战计划准备请求,在10 点 收到来自庞统发送的作战计划准备请求。

  • 接受者张飞(节点 Y)在9 点收到来自诸葛亮发送的作战计划准备请求,在 11 点 收到来自庞统发送的作战计划准备请求。

  • 接受者赵云(节点 Z)在 12 点 收到来自庞统发送的作战计划准备请求,在13 点收到来自诸葛亮发送的作战计划准备请求。

注意:准备阶段不需要携带具体的作战计划,所以作战计划可以为空,但是提议编号必须有。

收到准备请求(第一次)

按照接受请求的时间顺序,关羽和张飞收到诸葛亮的请求 [1,空],赵云收到庞统的请求 [2,空]

因为关羽、张飞之前没有收到提案,所以返回一个尚无提案的响应。也就是告诉诸葛亮,不会再响应编号小于等于 1 的准备请求了,也不会通过编号小于 1 的提案。响应的时间点是 14 点和 15 点

而赵云之前也没有收到提案,所以返回一个尚无提案的响应。也就是告诉庞统,不会再响应编号小于等于 2 的准备请求了,也不会通过编号小于 2 的提案。响应的时间点是 16 点

收到准备请求(第二次)

而对于庞统的准备请求,关羽、张飞收到编号为 2 的准备请求,而 编号 2 大于之前接受到的编号 1 ,而且关羽和张飞没有通过任何提案,所以还是会返回给庞统一个尚无提案 的响应。也就是告诉庞统不会再响应编号小于等于 2 的准备请求了,也不会通过编号小于 2 的提案。响应的时间点是 14 点和 15 点

而赵云最后收到诸葛亮编号为 1准备请求后,因编号 1小于之前响应的准备请求的提案编号 2,所以直接丢弃该准备请求,不做响应,如上图的 图示。

接受阶段

发送接受请求

诸葛亮和庞统收到准备响应后,会分别发送接受请求,如下图所示:

诸葛亮收到大多数接受者(关羽和张飞)的准备响应后,根据响应中提案编号最大的提案的值,设置接受请求中的值。因为关羽和张飞返回的准备响应都是尚无提案,所以还是发送提案编号为 1,提案值为接受请求代表从北边进攻曹操。发送的时间点是 15 点过 1 分、16 点

为什么是 15 点过 1 分? 因为只要满足大多数接受者的准备请求后,就可以发送接受请求了。关羽和张飞响应的时间点是 14 点和 15 点,所以 15 点以后就可以发送了。

庞统收到大多数接受者(关羽、张飞和赵云)的准备响应后,根据响应中提案编号最大的提案的值,,设置接受请求中的值。因为关羽、张飞和赵云返回的准备响应都是尚无提案,所以还是发送提案编号为 2,提案值为接受请求代表从南边进攻曹操。发送的时间点是 18 点、19 点、20 点

收到接受请求

当关羽、张飞、赵云收到诸葛亮和庞统的接受请求后,会进行如下处理,如下图所示:

关羽、张飞、赵云收到诸葛亮发送的提案 [1,北]时候,因为提案编号 1小于他们承诺的能通过的提案的最小提案编号 2,所以诸葛亮的提案被拒绝了。

而当他们收到庞统的发送的提案 [2,南] 的时候,因为编号 2 不小于之前承诺的编号 2,所以通过庞统的提案 [2,南] ,所以关羽、张飞、赵云他们的作战计划是从南边进攻曹操。达成了共识

学习者登场

当接受者通过了一个提案时,就通知所有的学习者。当学习者发现大多数的接受者都通过了某个提案,那么学习者也会通过该提案,接受该提案的值。

也就是说关羽、张飞、赵云达成了共识后,学习者法正马良也同样通过从南边进攻的作战计划

总结

  • Basic Paxos 也是通过二阶段提交协议达成共识。准备阶段、接受阶段。不知道二阶段提交协议的,可以看我前面的文章。《用太极拳讲分布式理论,舒服!》

  • Basic Paxos 不仅仅实现了共识,还实现了容错。有少于一半的节点出现故障时,集群也能正常工作。文中也多次强调了大多数节点都同意的原则,而这个原则赋予了 Basic Paxos 容错的能力。

  • 提案编号代表优先级,保证了三个承诺:

    • 如果准备请求的提案编号,小于等于接受者已经响应的准备请求的提案编号,那么接受者将承诺不响应这个准备请求
    • 如果接受请求中的提案的提案编号,小于接受者已经响应的准备请求的提案,那么接受者将承诺不通过这个提案。
    • 如果接受者之前有通过提案,那么接受者将承诺,会在准备请求的响应中,包含已经通过的最大编号的提案信息。

加分题

如果关羽和张飞已经通过了提案 [2,南],而赵云还未通过任何提案,当第三名军师简雍提出一个提案,编号为 8,作战计划为从东边进攻曹操,也就是 [8, 东]的作战计划,那么最终关羽、张飞、赵云的作战计划是怎么样的?欢迎评论区留言。

我是悟空,努力变强,变身超级赛亚人!手写了一套 Spring Cloud 进阶教程和 PMP 刷题小程序。欢迎关注公众号:悟空聊架构

诸葛 VS 庞统,拿下 Paxos 共识算法的更多相关文章

  1. Paxos共识算法

    Paxos共识算法 paxos是一族用来解决分布式系统共识的基础算法,共识过程就是在一组节点上达成一个一致的结果.由于节点可能会错误,通讯消息也可能会丢失,所以建立共识是一个比较复杂的过程. paxo ...

  2. 分布式共识算法 (二) Paxos算法

    系列目录 分布式共识算法 (一) 背景 分布式共识算法 (二) Paxos算法 分布式共识算法 (三) Raft算法 分布式共识算法 (四) BTF算法 一.背景 1.1 命名 Paxos,最早是Le ...

  3. 区块链共识算法 PBFT(拜占庭容错)、PAXOS、RAFT简述

    共识算法 区块链中最重要的便是共识算法,比特币使用的是POS(Proof of Work,工作量证明),以太币使用的是POS(Proof of Stake,股权证明)使得算理便的不怎么重要了,而今PO ...

  4. Paxos分布式系统共识算法?我愿称其为点歌算法…

    原创:微信公众号 码农参上,欢迎分享,转载请保留出处. 哈喽大家好啊,我是Hydra. 分布式系统共识算法Paxos相信大家都不陌生,它被称为最难理解的算法不是没有道理的,首先,它的发表之路就充满了坎 ...

  5. [区块链] 共识算法之争(PBFT,Raft,PoW,PoS,DPoS,Ripple)

    近几天对区块链中几种常见的共识机制(PBFT,Raft,PoW,PoS,DPoS,Ripple)进行了总结.尽量使用简单易懂语言,篇幅较大,想了解的可以只读每个算法介绍中前边的原理.本篇文章主要参考& ...

  6. raft共识算法

    raft共识算法 分布式一致性问题 如果说,服务器只有一个节点,那么,要保证一致性,没有任何问题,因为所有读写都在一个节点上发生.那如果server端有2个.3个甚至更多节点,要怎么达成一致性呢?下面 ...

  7. 浅析Hyperledger Fabric共识算法 摘自http://www.cocoachina.com/blockchain/20180829/24728.html

    Hyperledger Fabric共识算法 区块链系统是一个分布式架构,交易账本信息由各个节点管理,组成一个庞大的分布式账本.在分布式系统中,各个节点收到的交易信息的顺序可能存在差异(例如,网络延迟 ...

  8. 共识算法:PBFT、RAFT

    转自:https://www.cnblogs.com/davidwang456/articles/9001331.html 区块链技术中,共识算法是其中核心的一个组成部分.首先我们来思考一个问题:什么 ...

  9. 分布式共识算法 (四) BTF算法(区块链使用)

    系列目录 分布式共识算法 (一) 背景 分布式共识算法 (二) Paxos算法 分布式共识算法 (三) Raft算法 分布式共识算法 (四) BTF算法 一.引子 前面介绍的算法,无论是 Paxos ...

随机推荐

  1. 使用Tomcat Native提升Tomcat IO效率

    目录 简介 Tomcat的连接方式 APR和Tomcat Native 在tomcat中使用APR 简介 IO有很多种,从最开始的Block IO,到nonblocking IO,再到IO多路复用和异 ...

  2. OpenCV Error: Assertion failed (src.size == dst.size && src.channels() == dst.channels()) in cvConvertScale

    发现问题:在做kinect采集的深度图去噪的时候遇到了cvConvertScale格式转换的问题. OpenCV Error: Assertion failed (src.size == dst.si ...

  3. 【Azure Developer】通过Azure提供的Azue Java JDK 查询虚拟机的CPU使用率和内存使用率

    问题描述 在Azure上创建虚拟机(VM)后,在门户上可以查看监控指标(Metrics),如CPU Usage,Memory,Disk I/O等.那如何通过Java 代码获取到这些指标呢? 关于VM ...

  4. 恋爱话术库撩妹至尊VIP版

    本软件来自互联网,解锁永久至尊VIP 是一款教你撩妹密语软件.和女生聊天没有话题? 不知道怎么逗乐女生? 女生生气了不会哄? 不知道怎么让女生愿意跟你聊下去? 不知道女生对你有没有意思? 遇到不知道怎 ...

  5. Docker(七): 安装Loki

    洛基(Loki),是北欧神话中的恶作剧和谎言之神,亦是火神.他是巨人法布提(Farbauti)和女巨人劳菲(Laufey)的儿子,阿萨神族主神奥丁(Odin)的义兄弟,虽然他比奥丁要年轻许多.但他的个 ...

  6. 测开之数据类型· 第3篇《列表推导式、字典推导式、2种方式创建生成器》

    坚持原创输出,点击蓝字关注我吧 作者:清菡 博客:oschina.云+社区.知乎等各大平台都有. 目录 一.列表推导式 二.字典推导式 三.2种方式创建生成器 1.生成器表达式 2.函数里面,通过 y ...

  7. Eureka系列(九)Eureka自我保护机制

      因为本篇简文并不是自己总结的,而是当了下搬运工,所以直接直接附上原作者博客链接. 参考链接:   1.SpringCloud Eureka自我保护机制   2.Spring Cloud Eurek ...

  8. MySQL高级部分理论知识细讲

    文章目录 一.数据库分区.分表.分库.分片 YesOk ,大家好 ,我是小刘,许久不见,甚是想念 ,小刘今天来带大家学习 分库分表的基础知识 1.1 单机数据库的瓶颈 单个表数据量越大,读写锁,插入操 ...

  9. 闭关修炼180天--手写持久层框架(mybatis简易版)

    闭关修炼180天--手写持久层框架(mybatis简易版) 抛砖引玉 首先先看一段传统的JDBC编码的代码实现: //传统的JDBC实现 public static void main(String[ ...

  10. EF快速入门--直接修改(简要介绍ObjectContext处理机制)

    原博文 http://www.cnblogs.com/fly_dragon/archive/2011/06/05/2073084.html ObjectContext的处理机制 ObjectConte ...