关于共识算法
2017-11-29 13:11
246 查看
实际上,要保障系统满足不同程度的一致性,往往需要通过共识算法来达成。
共识算法解决的是对某个提案(Proposal),大家达成一致意见的过程。提案的含义在分布式系统中十分宽泛,如多个事件发生的顺序、某个键对应的值、谁是领导……等等,可以认为任何需要达成一致的信息都是一个提案。
注:实践中,一致性的结果往往还需要客户端的特殊支持,典型地通过访问足够多个服务节点来验证确保获取共识后结果。
很可惜的是,现实中这样“完美”的系统并不存在,如响应请求往往存在时延、网络会发生中断、节点会发生故障、甚至存在恶意节点故意要破坏系统。
一般地,把故障(不响应)的情况称为“非拜占庭错误”,恶意响应的情况称为“拜占庭错误”(对应节点为拜占庭节点)。
对于要能容忍拜占庭错误的情况,一般包括 PBFT 系列、PoW 系列算法等。从概率角度,PBFT 系列算法是确定的,一旦达成共识就不可逆转;而 PoW 系列算法则是不确定的,随着时间推移,被推翻的概率越来越小。
当节点之间的通信网络自身不可靠情况下,很显然,无法确保实现共识。但好在,一个设计得当的网络可以在大概率上实现可靠的通信。
然而,即便在网络通信可靠情况下,一个可扩展的分布式系统的共识问题的下限是无解。
这个结论,被称为 FLP 不可能性 原理,可以看做分布式领域的“测不准原理”。
共识算法解决的是对某个提案(Proposal),大家达成一致意见的过程。提案的含义在分布式系统中十分宽泛,如多个事件发生的顺序、某个键对应的值、谁是领导……等等,可以认为任何需要达成一致的信息都是一个提案。
注:实践中,一致性的结果往往还需要客户端的特殊支持,典型地通过访问足够多个服务节点来验证确保获取共识后结果。
问题挑战
实际上,如果分布式系统中各个节点都能保证以十分强大的性能(瞬间响应、高吞吐)无故障的运行,则实现共识过程并不复杂,简单通过多播过程投票即可。很可惜的是,现实中这样“完美”的系统并不存在,如响应请求往往存在时延、网络会发生中断、节点会发生故障、甚至存在恶意节点故意要破坏系统。
一般地,把故障(不响应)的情况称为“非拜占庭错误”,恶意响应的情况称为“拜占庭错误”(对应节点为拜占庭节点)。
常见算法
针对非拜占庭错误的情况,一般包括 Paxos、Raft 及其变种。对于要能容忍拜占庭错误的情况,一般包括 PBFT 系列、PoW 系列算法等。从概率角度,PBFT 系列算法是确定的,一旦达成共识就不可逆转;而 PoW 系列算法则是不确定的,随着时间推移,被推翻的概率越来越小。
理论界限
搞学术的人都喜欢对问题先确定一个界限,那么,这个问题的最坏界限在哪里呢?很不幸,一般情况下,分布式系统的共识问题无解。当节点之间的通信网络自身不可靠情况下,很显然,无法确保实现共识。但好在,一个设计得当的网络可以在大概率上实现可靠的通信。
然而,即便在网络通信可靠情况下,一个可扩展的分布式系统的共识问题的下限是无解。
这个结论,被称为 FLP 不可能性 原理,可以看做分布式领域的“测不准原理”。
相关文章推荐
- 论C++STL源代码中关于堆算法的那些事
- 很不错的几篇关于算法的文章
- 关于字符串匹配算法的survey
- 算法(读书笔记):1.关于算法的零散小点
- 关于时间,日期,星期,月份的算法(Java中Calendar的使用方法)
- 关于网上python红包算法。
- 贪心算法,关于区间问题
- 关于Rijndael算法的加密
- 关于两幅图中相位查找的算法
- 关于Yuri Boykov and Vladimir Kolmogorov 于2004年提出的max flow / min cut的算法的详解
- 关于利用死锁定理关于化简资源分配图(RAG)算法中“两不点”备忘
- [以太坊源代码分析]III. 挖矿和共识算法的奥秘
- 关于网站抽奖活动算法的尝试
- 关于游戏《挑战巅峰》中铺砖算法的猜测 -Unity
- 关于常用排序等算法的例子整理
- C++ STL 中有关于for_each() 和 transform() 算法
- 关于RC系列密码算法
- 关于算法的一些资料
- Java,C++和Ruby的性能PK(续文)--关于凸包算法(convex hull)的效率
- 一个算法:关于如何判断两个时间是否在允许误差内相等