“区块链原理设计与应用”读书笔记4
分布式系统的核心问题
主要内容:
一致性问题 共识问题
一致性:分布式集群中多个服务节点,对给定的操作,根据给定的协议,对处理结果对外保持一致. 不在乎结果是否正确,而是保证对外呈现的状态一致.所有节点失败也是一种一致.
引起不一致的因素:
节点间网络通信的不可靠,消息延迟,消息乱序,内容错误.
节点处理时间无法保证: 结果可能错误,或者节点宕机.
满足一致性的要求:
1. 有限时间完成请求的处理2.不同节点完成的结果相同.3决策的结果必须是某个节点提出的提案.
强一致性需要 顺序保证. 时钟
共识:对某一操作,达成一直的过程.通常达成这个一过程需要集群中的节点进行广播投票.
但是由于分布式节点间的不稳定: 网络不可靠,节点宕机,假消息等.达成共识并不容易.
针对如上不稳定的情况,把故障分为:非拜占庭错误(出现消息不响应,但是消息不会被篡改)和拜占庭错误(存在伪造消息的情况).
共识算法:
CFT类 针对非拜占庭错误有: PAXOS 算法.Raft算法.
容错较好,处理快,保证不超过一半节点故障.
BFT类 针对拜占庭错误有: PBFT 确定性算法,POW 工作量证明的概率算法.
FLP不可能原理: 异步系统,不存在 任意场景下都能实现共识的算法.
分布式同步:系统各个节点时钟误差存在上限,消息传递必须在规定时间内完成,否则认为失败.(传统的分布式中,统一时钟,超时失败等都是同步)
分布式异步:系统各个节点时钟存在较大差距,消息传递时间任意长(无法判断节点故障还是网络延迟)
CAP 一致性 :分布式计算系统不可能同时保证 强一致性,高可用性,高分区容忍性.
折中选择:
弱化一致性:对结果不敏感的应用可以允许最终一致. CouchDB
弱化可用性:对结果一致性敏感,银行,当系统故障时会拒绝服务.MongoDB , Redis,MapReduce 为此设计. PAXOS 等共识算法主要处理这种情况. 可能存在无法提供可用结果的情况,同时允许部分节点离线.
弱化分区容忍性: 网络分区出现概率较小, 两阶段提交算法,关系型数据库,ZK主要考虑这种情况设计的.实践中网络可用是双通道,弱化网络不稳定因素.
PAXOS 算法:
节点分为三种角色:
① 提案者:提出提案,系统提案都有自增ID,(往往是客户端担任)
② 接受者:对提出的提案进行投票(服务端)
③ 学习者:对投票传播学习,不参与投票
约束条件:
①保证决议结果是正确的,不会出现错误.只有被提案者提出的提案才会被投票接受.一次执行中被多数接受的提案成为最终决议
②保证决议在有限时间内完成,决议总会产生,并且学习者会接受决议
过程:
RAFT算法:
PBFT 算法:
POW算法 :
整理者（ghc 刘大双 李志强）