转载请注明出处 http://www.paraller.com
原文排版地址 点击跳转算法
应用场景:在分布式系统中,每一个节点虽然能够知晓本身的操做时成功或者失败,却没法知道其余节点的操做的成功或失败。
当一个事务跨越多个节点时,为了保持事务的 ACID 特性,须要引入一个做为协调者的组件来统一掌控全部节点(称做参与者)的操做结果并最终指示这些节点是否要把操做结果进行真正的提交(好比将更新后的数据写入磁盘等)。数据库
一、同步阻塞操做,必然会很是大地影响性能。网络
二、另外是超时问题,好比,框架
糟糕的状况是,第二阶段中,若是参与者收不到协调者的 commit/fallback 指令,参与者将处于“状态未知”阶段,参与者彻底不知道要怎么办,好比:若是全部的参与者完成第一阶段的回复后(可能所有 yes,可能所有 no,分布式
可能部分 yes 部分 no),若是协调者在这个时候挂掉了。那么全部的结点彻底不知道怎么办(问别的参与者都不行)。为了一致性,要么死等协调者,要么重发第一阶段的 yes/no 命令。
(事务及分布式事务)[http://blog.daocloud.io/micro...]性能
CAP 定理:一个分布式系统最多只能同时知足一致性
(Consistency)、可用性
(Availability)和分区容错性
(Partition tolerance)这三项中的两项。网站
一致性指更新操做成功后,全部节点在同一时间的数据彻底一致。常见的一致性类别:搜索引擎
常见的分布式系统中,总会发生诸如机器宕机或网络异常(包括消息的延迟、丢失、重复、乱序,还有网络分区)等状况。设计
Paxos 算法须要解决的问题就是如何在一个可能发生上述异常的分布式系统中,快速且正确地在集群内部对某个数据的值达成一致,而且保证不论发生以上任何异常,都不会破坏整个系统的一致性。
Raft是斯坦福的 Diego Ongaro、John Ousterhout 两我的以易懂(Understandability)为目标设计的一致性算法,在 2013 年发布了论文:In Search of an Understandable Consensus Algorithm
从 2013 年发布到如今不过只有两年,到如今已经有了十多种语言的 Raft 算法实现框架code