“区块链原理设计与应用”读书笔记4

分布式系统的核心问题

主要内容:

一致性问题 共识问题

一致性:分布式集群中多个服务节点,对给定的操作,根据给定的协议,对处理结果对外保持一致. 不在乎结果是否正确,而是保证对外呈现的状态一致.所有节点失败也是一种一致.

引起不一致的因素:

节点间网络通信的不可靠,消息延迟,消息乱序,内容错误.

节点处理时间无法保证: 结果可能错误,或者节点宕机.

满足一致性的要求:

1. 有限时间完成请求的处理2.不同节点完成的结果相同.3决策的结果必须是某个节点提出的提案.

强一致性需要 顺序保证. 时钟

共识:对某一操作,达成一直的过程.通常达成这个一过程需要集群中的节点进行广播投票.

但是由于分布式节点间的不稳定: 网络不可靠,节点宕机,假消息等.达成共识并不容易.

针对如上不稳定的情况,把故障分为:非拜占庭错误(出现消息不响应,但是消息不会被篡改)和拜占庭错误(存在伪造消息的情况).

共识算法:

CFT类 针对非拜占庭错误有: PAXOS 算法.Raft算法.

 容错较好,处理快,保证不超过一半节点故障.

BFT类 针对拜占庭错误有: PBFT 确定性算法,POW 工作量证明的概率算法.

FLP不可能原理: 异步系统,不存在 任意场景下都能实现共识的算法.

分布式同步:系统各个节点时钟误差存在上限,消息传递必须在规定时间内完成,否则认为失败.(传统的分布式中,统一时钟,超时失败等都是同步)

分布式异步:系统各个节点时钟存在较大差距,消息传递时间任意长(无法判断节点故障还是网络延迟)

CAP 一致性 :分布式计算系统不可能同时保证 强一致性,高可用性,高分区容忍性.

折中选择:

弱化一致性:对结果不敏感的应用可以允许最终一致. CouchDB

弱化可用性:对结果一致性敏感,银行,当系统故障时会拒绝服务.MongoDB , Redis,MapReduce 为此设计. PAXOS 等共识算法主要处理这种情况. 可能存在无法提供可用结果的情况,同时允许部分节点离线.

弱化分区容忍性: 网络分区出现概率较小, 两阶段提交算法,关系型数据库,ZK主要考虑这种情况设计的.实践中网络可用是双通道,弱化网络不稳定因素.

PAXOS 算法:

节点分为三种角色:

① 提案者:提出提案,系统提案都有自增ID,(往往是客户端担任)

② 接受者:对提出的提案进行投票(服务端)

③ 学习者:对投票传播学习,不参与投票

约束条件:

①保证决议结果是正确的,不会出现错误.只有被提案者提出的提案才会被投票接受.一次执行中被多数接受的提案成为最终决议

②保证决议在有限时间内完成,决议总会产生,并且学习者会接受决议

过程:


RAFT算法:

PBFT 算法:

POW算法 :

 整理者(ghc 刘大双 李志强)

猜你喜欢

转载自blog.csdn.net/java_hhhh/article/details/79701903
今日推荐