分布式一致性算法

sschrodinger

2019/07/17

一个分布式系统 不可能同时满足 一致性（ C:Consistency )，可用性（ A: Availability ）和分区容错性（ P：Partition tolerance ）这三个基本需求， 最多只能同时满足其中的 2 个 。

如下：

BASE 是 Basically Available (基本可用) ，Soft state （软状态）,和 Eventually consistent （最终一致性）三个短语的缩写。

既是无法做到 强一致性 （ Strong consistency ），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到 最终一致性 （ Eventual consistency ）

基本可用

允许出现响应时间损失或者功能损失。

软状态

允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即 允许系统在多个不同节点的数据副本存在数据延时 。

最终一致性

系统能够保证 在没有其他新的更新 *** 作 的情况下，数据最终一定能够达到一致的状态，因此所有客户端对系统的数据访问 最终都能够获取到最新的值 。

在分布式系统中，会有多个机器节点，因此需要一个 “ 协调者 ” ，而各个节点就是 “ 参与者 ”，协调者统一调度所有分布式节点的执行逻辑，这些被调度的分布式节点就是 “参与者”。

阶段一

阶段一主要是询问参与者是否可以进行提交。

阶段二

阶段二会根据阶段一的投票结果执行两种 *** 作： 执行事务提交 ， 回滚事务 。

执行事务提交步骤如下：

中断事务步骤如下：

优点

原理简单，实现方便

缺点

同步阻塞，单点问题，数据不一致，过于保守

2PC （两阶段提交协议）

三阶段提交协议在协调者和参与者中都引入 超时机制 ，并且把两阶段提交协议的第一个阶段拆分成了两步：询问，然后再锁资源，最后真正提交。

协调流程如下：

阶段一： CanCommit

阶段二：preCommit

协调者在得到所有参与者的响应之后，会根据结果执行2种 *** 作：执行 事务预提交 ，或者 中断事务 。

执行事务预提交分为 3 个步骤：

中断事务也分为2个步骤：

阶段三：doCommit

该阶段做真正的提交，同样也会出现两种情况：

执行提交

中断事务

假设有任何参与者反馈了 no 响应，或者超时了，就中断事务。

优点

缺点

如果参与者收到了 preCommit 消息后，出现了网络分区，那么参与者等待超时后，都会进行事务的提交，这必然会出现事务不一致的问题

3PC（三阶段提交协议）

paxos 算法保证了一致性 。

在一个分布式系统中，有一组的 process，每个 process 都可以提出一个 value，consensus 算法就是用来从这些 values 里选定一个最终 value。如果没有 value 被提出来，那么就没有 value 被选中；如果有1个 value 被选中，那么所有的 process 都应该被通知到。

在 2PC 或者 3PC 中，如果协调者宕机了，整个系统就宕机了，这个时候就需要引用多个协调者，paxos 就是用来协调协调者的协议。

首先将议员的角色分为 proposers ， acceptors ，和 learners （允许身兼数职）。 proposers 提出提案，提案信息包括提案编号和提议的 value ； acceptor 收到提案后可以接受（ accept ）提案，若提案获得多数派（ majority ）的 acceptors 的接受，则称该提案被批准（ chosen ）； learners 只能“学习”被批准的提案。划分角色后，就可以更精确的定义问题：

通过不断加强上述3个约束（主要是第二个）获得了 Paxos 算法。

批准 value 的过程中，首先 proposers 将 value 发送给 acceptors ，之后 acceptors 对 value 进行接受（ accept ）。为了满足只批准一个 value 的约束，要求经“多数派（ majority ）”接受的 value 成为正式的决议（称为“批准”决议）。这是因为无论是按照人数还是按照权重划分，两组“多数派”至少有一个公共的 acceptor ，如果每个 acceptor 只能接受一个 value ，约束 2 就能保证。

于是产生了一个显而易见的新约束：

注意 P1 是不完备的。 如果恰好一半 acceptor 接受的提案具有 value A ，另一半接受的提案具有 value B ，那么就无法形成多数派 ，无法批准任何一个 value 。

约束 2 并不要求只批准一个提案 ，暗示可能存在多个提案。 只要提案的 value 是一样的，批准多个提案不违背约束 2 。于是可以产生约束 P2：

如果 P1 和 P2 都能够保证，那么约束 2 就能够保证。

批准一个 value 意味着多个 acceptor 接受（ accept ）了该 value 。因此，可以对 P2 进行加强：

由于通信是异步的，P2a 和 P1 会发生冲突。如果一个 value 被批准后，一个 proposer 和一个 acceptor 从休眠中苏醒，前者提出一个具有新的 value 的提案。根据 P1，后者应当接受，根据 P2a，则不应当接受，这种场景下 P2a 和 P1 有矛盾。于是需要换个思路，转而对 proposer 的行为进行约束：

由于 acceptor 能接受的提案都必须由 proposer 提出，所以 P2b 蕴涵了 P2a，是一个更强的约束。

但是根据 P2b 难以提出实现手段。因此需要进一步加强 P2b。

假设一个编号为 m 的 value v 已经获得批准（ chosen ），来看看在什么情况下对任何编号为 n （ n > m ）的提案都含有 value v 。因为 m 已经获得批准（ chosen ），显然存在一个 acceptors 的多数派 C ，他们都接受（ accept ）了 v 。考虑到任何多数派都和 C 具有至少一个公共成员，可以找到一个蕴涵 P2b 的约束 P2c：

如果一个没有 chose 过任何 proposer 提案的 acceptor 在 prepare 过程中接受了一个 proposer 针对提案 n 的问题，但是在开始对 n 进行投票前，又接受（ accept ）了编号小于n的另一个提案（例如 n-1 ），如果 n-1 和 n 具有不同的 value ，这个投票就会违背 P2c。因此在 prepare 过程中， acceptor 进行的回答同时也应包含承诺：不会再接受（ accept ）编号小于 n 的提案。这是对 P1 的加强：

通过一个决议分为两个阶段：

prepare 阶段

proposer 选择一个提案编号 n 并将 prepare 请求发送给 acceptors 中的一个多数派；

acceptor 收到 prepare 消息后，如果提案的编号大于它已经回复的所有 prepare 消息(回复消息表示接受 accept )，则 acceptor 将自己上次接受的提案回复给 proposer ，并承诺不再回复小于 n 的提案；

批准阶段

当一个 proposer 收到了多数 acceptors 对 prepare 的回复后，就进入批准阶段。 它要向回复 prepare 请求的 acceptors 发送 accept 请求，包括编号 n 和根据 P2c 决定的 value （如果根据 P2c 没有已经接受的 value ，那么它可以自由决定 value ） 。
在不违背自己向其他 proposer 的承诺的前提下， acceptor 收到 accept 请求后即批准这个请求。

这个过程在任何时候中断都可以保证正确性。例如如果一个 proposer 发现已经有其他 proposers 提出了编号更高的提案，则有必要中断这个过程。因此为了优化，在上述 prepare 过程中，如果一个 acceptor 发现存在一个更高编号的提案，则需要通知 proposer ，提醒其中断这次提案。

一个实例如下：

在这之后，提议者还需要做一件事，就是告知D,E，被决定的决议已经是什么了。即可。

这个过程叫 Learn 。 D ， E 被称为 Learner

Paxos VS Zab

wiki 百科

维基百科-paxos

对于 paxos 来说，每一个议案都要经过不同节点的提出，并且讨论，在提出一个议案的阶段，另外的提议会被否决，导致了性能的低下。

ZAB 协议是为分布式协调服务 Zookeeper 专门设计的一种支持 崩溃恢复 和 原子广播 协议。

基于该协议， Zookeeper 实现了一种 主备模式 的系统架构来保持集群中各个副本之间数据一致性。具体如下图所示：

即只有一个 proposal 可以提出提议，其他的进程都只能复制决议。

所有客户端写入数据都是写入到 主进程（称为 Leader ）中，然后，由 Leader 复制到备份进程（称为 Follower ）中。从而保证数据一致性。

ZAB 协议的消息广播过程使用的是一个原子广播协议，类似一个 二阶段提交过程 。但是只需要 Follower 有一半以上返回 Ack 信息就可以执行提交，大大减小了同步阻塞。也提高了可用性。

对于客户端发送的写请求，全部由 Leader 接收， Leader 将请求封装成一个事务 Proposal ，将其发送给所有 Follwer ，然后，根据所有 Follwer 的反馈，如果超过半数成功响应，则执行 commit *** 作（先提交自己，再发送 commit 给所有 Follwer ）。

流程如下：

Leader 挂了之后， ZAB 协议就自动进入崩溃恢复模式，选举出新的 Leader ，并完成数据同步，然后退出崩溃恢复模式进入消息广播模式。

可能 Leader 遇到如下异常情况：

第一种情况 主要是当 leader 收到合法数量 follower 的 ACKs 后，就向各个 follower 广播 COMMIT 命令，同时也会在本地执行 COMMIT 并向连接的客户端返回「成功」。 但是如果在各个 follower 在收到 COMMIT 命令前 leader 就挂了，导致剩下的服务器并没有执行都这条消息。

为了实现已经被处理的消息不能丢这个目的，Zab 的恢复模式使用了以下的策略：

第二种情况 主要是当 leader 接收到消息请求生成 proposal 后就挂了，其他 follower 并没有收到此 proposal ，因此经过恢复模式重新选了 leader 后，这条消息是被跳过的( 其他机器日志中没有这一条记录，但是他的日志中有这一条记录 )。 此时，之前挂了的 leader 重新启动并注册成了 follower ，他保留了被跳过消息的 proposal 状态，与整个系统的状态是不一致的， 需要将其删除 。

Zab 通过巧妙的设计 zxid 来实现这一目的。一个 zxid 是 64 位，高 32 是纪元（ epoch ）编号，每经过一次 leader 选举产生一个新的 leader ，新 leader 会将 epoch + 1 。低 32 位是消息计数器，每接到一个消息，则 $lo^{32} + 1$ ，新 leader 选举后这个值重置为 0。这样设计的好处是旧的 leader 挂了后重启，它不会被选举为 leader ，因为此时它的 zxid 肯定小于当前的新 leader 。当旧的 leader 作为 follower 接入新的 leader 后，新的 leader 会让它将所有的拥有旧的 epoch 未被 COMMIT 的 proposal 清除。

Zookeeper系列（5）--ZAB协议，消息广播，崩溃恢复，数据同步

Raft是用于管理复制日志的一致性算法，raft 协议也是一个 主备模型 ，有一个唯一的 leader 控制任务的提交。

如下是一个 raft 协议中每一个节点可能存在的状态，主要分为 领袖 、 群众 和 候选人 。

raft 最关键的一个概念是任期，每一个 leader 都有自己的任期，必须在任期内发送心跳信息给 follower 来延长自己的任期。

Raft 协议强依赖 Leader 节点的可用性来确保集群数据的一致性 。 数据的流向只能从 Leader 节点向 Follower 节点转移 。当 Client 向集群 Leader 节点提交数据后， Leader 节点接收到的数据处于 未提交状态（ Uncommitted ） ，接着 Leader 节点会 并发向所有 Follower 节点复制数据 并等待接收响应，确保 至少集群中超过半数节点 已接收到数据后再向 Client 确认数据已接收。一旦向 Client 发出数据接收 Ack 响应后，表明此时数据状态进入已提交（ Committed ）， Leader 节点再向 Follower 节点发通知告知该数据状态已提交。

在数据同步阶段，可能出现七种情况：

动画演示 raft 算法

动画演示 raft 算法 - 2

Raft Vs zab

NWR 是一种在分布式存储系统中用于控制一致性级别的一种策略。在 Amazon 的 Dynamo 云存储系统中，就应用 NWR 来控制一致性。

让我们先来看看这三个字母的含义：

在分布式系统中， 数据的单点是不允许存在的 。即线上正常存在的 Replica 数量是 1 的情况是非常危险的，因为一旦这个 Replica 再次错误，就 可能发生数据的永久性错误。假如我们把 N 设置成为 2，那么，只要有一个存储节点发生损坏，就会有单点的存在。所以 N 必须大于 2。N约高，系统的维护和整体 成本就越高。工业界通常把 N 设置为3。
当 W 是 2、R 是 2 的时候， W+R>N ，这种情况对于客户端就是强一致性的。

在具体实现系统时，仅仅依靠 NWR 协议还不能完成一致性保证，因为在上述过程中，当读取到多个备份数据时，需要判断哪些数据是最新的，如何判断数据的新旧？这需要向量时钟来配合，所以对于 Dynamo 来说，是通过NWR协议结合向量时钟来共同完成一致性保证的。

阿粉最近迷上了 Redis，为什么呢？感觉 Redis 确实功能很强大呀，一个基于内存的系统 Key-Value 存储的数据库，竟然有这么多的功能，而阿粉也要实实在在地把 Redis 来弄一下，毕竟面试的时候，Redis 可以说是一个非常不错的加分项。

为什么需要分布式锁？

目前很多的大型项目全部都是基于分布式的，而分布式场景中的数据一致性问题一直是一个不可忽视的问题，大家知道关于分布式的 CAP 理论么？

CAP 理论就是说任何一个分布式系统都无法同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance），最多只能同时满足两项。

而我们的系统最终满足的永远都是最终一致性，而这种最终一致性，有些时候有人会喜欢问关于分布式事务，而有些人则偏重在分布式锁上。

但是阿粉选择的就是使用缓存来实现分布式锁，也就是我们在项目中最经常使用的 Redis ，谈到 Redis，那真是可以用在太多地方了，比如说：

我们今天就来实现用 Redis 来实现分布式锁，并且要学会怎么使用。

1准备使用 Jedis 的 jar 包，在项目中导入 jar 包。

jedisset(lockKey, requestId, SET_IF_NOT_EXIST, SET_WITH_EXPIRE_TIME, expireTime); 这个加锁的姿势才是我们最需要了解的，不然你用的时候都不知道怎么使用。

key：加锁的键，实际上就是相当于一个唯一的标志位，不同的业务，你可以使用不同的标志位进行加锁。

requestId：这个东西实际上就是用来标识他是哪一个请求进行的加锁，因为在分布式锁中，我们要知道一件事，就是加锁的和解锁的，必须是同一个客户端才可以。

而且还有一种比较经典的就是 B 把 A 的锁给释放了，导致释放混乱，如果你不加相同的请求，A 线程处理业务，执行了加锁，锁的过期时间是5s, B线程尝试获取锁，如果 A 处理业务时间超过5s，这时候 A 就要开始释放锁，而B在这时候没有检测到这个锁，从而进行了加锁，这时候加锁的时候，A还没处理完对应业务，当他处理完了之后，再释放锁的话，要是就是直接把 B 刚加的锁释放了，要么就是压根都没办法释放锁。

SET_IF_NOT_EXIST：看字面意思，如果 key 不存在，我们进行Set *** 作，如果存在，啥都不干，也就不在进行加锁。

SET_WITH_EXPIRE_TIME：是否过期

expireTime：这是给 key 设置一个过期的时间，万一你这业务一直被锁着了，然后之后的业务想加锁，你直接给一直持有这个这个锁，不进行过期之后的释放，那岂不是要凉了。

上面的方法中 tryGetDistributedLock 这个方法也就是我们通常使用的加锁的方法。

大家看到这个 script 的时候，会感觉有点奇怪，实际上他就是一个 Lua 的脚本，而 Lua 脚本的意思也比较简单。

其实这时候就有些人说，直接 del 删除不行么？你试试你如果这么写的话，你们的领导会不会把你的腿给你打断。

这种不先判断锁的拥有者而直接解锁的方式，会导致任何客户端都可以随时进行解锁，也就是说，这锁就算不是我加的，我都能开，这怎么能行呢？

在这里给大家放一段使用的代码，比较简单,但是可以直接用到你们的项目当中

我们先把这个实现方式实现了，然后我们再来说说大家最不愿意看的理论知识，毕竟这理论知识是你面试的时候经常会被问到的。

分布式CAP理论：

加州大学伯克利分校的 Eric Brewer 教授在 ACM PODC 会议上提出 CAP 猜想。2年后，麻省理工学院的 Seth Gilbert 和 Nancy Lynch 从理论上证明了 CAP。之后，CAP 理论正式成为分布式计算领域的公认定理。

也就是说，在二十年前的时候，CAP 理论只是个猜想。结果两年之后被证实了，于是，大家在考虑分布式的时候，就有根据来想了，不再是空想了。

什么是分布式的 CAP 理论 ？

一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项

这个和(Atomicity)不太一样，因为之前看有些人说，在 CAP 理论中的 A 和数据库事务中的 A 是一样的，单词都不一样，那能一样么？

Availability ：分布式中的 A 表示的是可用性，也就是说服务一直可用，而且是正常响应时间。

而你在搭建分布式系统的时候，要保证每个节点都是稳定的，不然你的可用性就没有得到相对应的保证，也谈不上是什么分布式了。只能称之为一个伪分布式。

Consistency： 一致性

也就是说你的更新 *** 作成功并返回客户端完成后，所有节点在同一时间的数据完全一致，这个如果你在使用 Redis 做数据展示的时候，很多面试官都会问你，那你们是怎么保证数据库和缓存的一致性的呢？

毕竟你只是读取的话，没什么问题，但是设计到更新的时候，不管是先写数据库，再删除缓存；还是先删除缓存，再写库，都有可能出现数据不一致的情况。

所以如果你对这个很感兴趣，可以研究一下，比如说：

如果你能在面试的时候把这些都给面试官说清楚，至少感觉你应该能达到你自己的工资要求。

Partition tolerance:分区容错性

分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务。

其实在 CAP 理论当中，我们是没有办法同时满足一致性、可用性和分区容错性这三个特性，所以有所取舍就可以了。

关于使用 Redis 分布式锁，大家学会了么？

现今互联网界，分布式系统和微服务架构盛行。一个简单 *** 作，在服务端非常可能是由多个服务和数据库实例协同完成的。在一致性要求较高的场景下，多个独立 *** 作之间的一致性问题显得格外棘手。
基于水平扩容能力和成本考虑，传统的强一致的解决方案（eg单机事务）纷纷被抛弃。其理论依据就是响当当的CAP原理。往往为了可用性和分区容错性，忍痛放弃强一致支持，转而追求最终一致性。
分布式系统的特性
在分布式系统中，同时满足CAP定律中的一致性 Consistency、可用性 Availability和分区容错性 Partition Tolerance三者是不可能的。在绝大多数的场景，都需要牺牲强一致性来换取系统的高可用性，系统往往只需要保证最终一致性。
>PoW 、PoS 、DPOW都是什么意思？
说到区块链，我们必然会谈及它的共识机制。不了解区块链的共识机制，就无法理解区块链的真正意义。那么，今日份的区块链的共识机制了解一下？
共识机制是什么？
什么是共识？直取它的字面意思，就是"共同的认识"
人与人是不同的，这种不同不仅体现在身材、长相、能力，更体现在文化、观点、想法、利益诉求等等方面。
共识，简而言之，就是一个群体的成员在某一方面达成的一致意见。
我们了解到，信任是社会运转中的一大痛点，银行有自己的信用体系，过去的金融体系服务于只服务于极少的企业家，因为建立信用体系耗资巨大。后来支付宝有了芝麻信用，信用已经关系到生活的很多方面，xyk额度、花呗额度，芝麻信用高出国还可以免签。我们正享受着信用给我们带来的便捷。
区块链本质是去中心化，去中心化的核心是共识机制，区块链上的共识机制主要解决由谁来构造区块，以及如何维护区块链统一的问题。
区块链共识机制的目标是使所有的诚实节点保存一致的区块链视图，同时满足两个性质：
1）一致性：所有诚实节点保存的区块链的前缀部分完全相同。
2）有效性：由某诚实节点发布的信息终将被其他所有诚实节点记录在自己的区块链中。
区块链的自信任主要体现于分布于区块链中的用户无须信任交易的另一方，也无须信任一个中心化的机构，只需要信任区块链协议下的软件系统即可实现交易。
共识机制是什么？PoW 、PoS 、DPOW都是什么意思？
共识机制的必要性？
分布式系统中，多个主机通过异步通信方式组成网络集群。在这样的一个异步系统中，需要主机之间进行状态复制，以保证每个主机达成一致的状态共识。错误信息可能出现在异步系统内并不断传播，因此需要在默认不可靠的异步网络中定义容错协议，以确保各主机达成安全可靠的状态共识，这就是共识机制诞生的必要性。
这种自信任的前提是区块链的共识机制（consensus），即在一个互不信任的市场中，要想使各节点达成一致的充分必要条件是每个节点出于对自身利益最大化的考虑，都会自发、诚实地遵守协议中预先设定的规则，判断每一笔记录的真实性，最终将判断为真的记录记入区块链之中。attachments-2018-08-9yY7VRHa5b738e3d96021jpg
换句话说，如果各节点具有各自独立的利益并互相竞争，则这些节点几乎不可能合谋欺骗你，而当节点们在网络中拥有公共信誉时，这一点体现得尤为明显。区块链技术正是运用一套基于共识的数学算法，在机器之间建立"信任"网络，从而通过技术背书而非中心化信用机构来进行全新的信用创造。
当今区块链的几种共识机制介绍
区块链上的共识机制有多种，但任何一种都不是完美无缺，或者说适用于所有应用场景的。
PoW 工作量证明
整个系统中每个节点为整个系统提供计算能力（简称算力），通过一个竞争机制，让计算工作完成最出色的节点获得系统的奖励，即完成新生成货币的分配，简单理解就是多劳多得，bitcoin、LTC等货币型区块链就应用POW机制。
优点
完全去中心化节点自由进出，算法简单，容易实现破坏系统花费的成本巨大，只要网络破坏者的算力不超过网络总算力的50%,网络的交易状态就能达成一致
缺点
浪费能源，这是最大的缺点区块的确认时间难以缩短，如bitcoin每秒只能做7笔交易，不适合商业应用新的区块链必须找到一种不同的散列算法，否则就会面临bitcoin的算力攻击对节点的性能网络环境要求高容易产生分叉，需要等待多个确认无法达成最终一致性
PoS 权益证明
也称股权证明，类似于你把财产存在银行，这种模式会根据你持有加密货币的数量和时间，分配给你相应的利息。
优点
对节点性能要求低，达成共识时间短
缺点
没有最终一致性，需要检查点机制来弥补最终性
DPOW 委托股权证明
DPOW是 PoS 的进化方案，在常规 PoW和 PoS 中，任何一个新加入的区块，都需要被整个网络所有节点做确认，非常影响效率。
DPoS则类似于现代董事会的投票机制，通过选举代表来进行投票和决策。被选举出的n个记账节点来做新区块的创建、验证、签名和相互监督，这样就极大地减少了区块创建和确认所需要消耗的时间和算力成本。
优点
大幅缩小参与验证和记账节点的数量，可以达到秒级的共识验证
缺点
牺牲了去中心化的概念，不适合公有链
PBFT 实用拜占庭容错
实用拜占庭容错机制是一种采用"许可投票、少数服从多数"来选举领导者并进行记账的共识机制，该共识机制允许拜占庭容错，允许强监督节点参与，具备权限分级能力，性能更高，耗能更低，而且每轮记账都会由全网节点共同选举领导者，允许33%的节点作恶，容错率为33%实用拜占庭容错特别适合联盟链的应用场景。
优点
会背离中心化，加密货币的存在及奖励机制会产生马太效应，让社区中的穷者更穷，富者更富共识效率高，可实现高频交易
缺点
当系统只剩下33%的节点运行时，系统会停止运行
dBFT 授权拜占庭容错
这种机制是用权益来选出记账人，然后记账人之间通过拜占庭容错算法达成共识。授权拜占庭容错机制最核心的一点，就是最大限度地确保系统的最终性，使区块链能够适用于真正的金融应用场景。
优点
专业化的记账人可以容忍任何类型的错误记账由多人协同完成，每一个区块都有最终性，不会分叉算法的可靠性有严格的数学证明
缺点
当三分之一或以上记账人停止工作后，系统将无法提供服务当三分之一或以上记账人联合作恶，可能会使系统出现分叉
Pool 验证池
基于传统的分布式一致性技术，加上数据验证机制。
优点
不需要加密货币也可以工作，在成熟的分布式一致性算法（Pasox、Raft）基础上，实现秒级共识验证。
缺点
去中心化程度不如bitcoin,更适合多方参与的多中心商业模式。
Paxos
这是一种传统的分布式一致性算法，是一种基于选举领导者的共识机制。领导者节点拥有绝对权限，并允许强监督节点参与，其性能高，资源消耗低。所有节点一般有线下准入机制，但选举过程中不允许有作恶节点，不具备容错性。
Paxos算法中将节点分为三种类型：
proposer:提出一个提案，等待大家批准为结案。往往是客户端担任该角色
acceptor:负责对提案进行投票。往往是服务端担任该角色
learner:被告知结案结果，并与之统一，不参与投票过程。可能为客户端或服务端
Paxos 能保证在超过50%的正常节点存在时，系统能达成共识。
瑞波共识机制
瑞波共识算法使一组节点能够基于特殊节点列表形成共识，初始特殊节点列表就像一个俱乐部，要接纳一个新成员，必须由该俱乐部51%的会员投票通过。共识遵循这些核心成员的"51%权利",外部人员则没有影响力。由于该俱乐部由中心化开始，它将一直是中心化的，而如果它开始腐化，股东们什么也做不了。与bitcoin及Peercoin一样，瑞波系统将股东们与其投票权隔开，因此，它比其他系统更中心化。
Peercoin
Peercoin（点点币，PPC），混合了POW工作量证明及POS权益证明方式，其中POW主要用于发行货币，未来预计随着挖矿难度上升，产量降低，系统安全主要由POS维护。
在区块链网络中，由于应用场景的不同，所设计的目标各异，不同的区块链系统采用了不同的共识算法。每种共识算法都不是完美的，都有其优点和局限性。
区块链解决了在不可信信道上传输可信信息、价值转移的问题，而共识机制解决了区块链如何分布式场景下达成一致性的问题。
虽然区块链目前还处于发展的早期，行业发展还面临着一些阻碍，但社会已经足够多地认识到区块链的价值，区块链发展的脚步绝不会停滞不前，行业发展也定会找到突破阻碍的方法。

---