一致性算法

很多人举例乱七八糟,吃饭,旅游,贿赂什么都有,计算机的问题,扯那么多无关紧要的内容,累赘,尴尬病都犯了。简单的东西,直说就行,拐着弯介绍,越说越偏。计算机的问题,就用代码的思维去理解,代码不存在模棱两可的解释,而那些所谓的举例,往往产生各种理解上的偏颇。以为懂了,最后用代码去实现,还是一脸懵逼。知乎上很多回答,动不动就举个自以为巧妙的例子,其实不举那些奇奇怪怪的例子,简单地直属是最好的,引入什么例子太多余。计算机的概念,举个实际生产环境下的例子就行,扯什么吃饭,旅游,尬的慌。程序的流程图,模块图,uml图,时序图一画,立马一目了然。为了举例而去举例,以为举例能便于理解,然而适得其反。

共识算法,在分布式系统里面,就是选举出一台master机器,mysql的master slave知道吧,就是那个master的意思。

那么在这个场景下,paxos中的提议是什么呢,就是向acceptor提议自己要当master。proposer需要提交编号n和value,有人把编号人举例子为贿赂,这不扯淡么,越扯越远。n就是一个随机数,如果是贿赂,每个贿赂者出最高不就完了么,最高是什么?int或long的最大值。

Prepare阶段

Paxos算法描述非常的简单,就只有两步,决议的提出(Prepare)与批准(Accept)。就这么一句话,你懂了么?是不是云里雾里的。

Prepare阶段proposer选择一个提案编号n并将Prepare请求发送给acceptors中的一个多数派(即超过半数);acceptor收到Prepare消息后,如果提案的编号大于它已经回复的所有Prepare消息,则acceptor将自己上次接受的提案回复给proposer,并承诺不再回复小于n的提案;

批准阶段

当一个proposer收到了多数acceptors对Prepare的回复后,就进入批准阶段。它要向回复Prepare请求的acceptors发送accept请求,包括编号n和value;在不违背自己向其他proposer的承诺的前提下,acceptor收到accept请求后即接受这个请求。

proposer是怎么发送request和propose的,发一个request再发一个propose,还是,先对所有acceptor发request,再发送proposal.

分布式环境非常复杂,可能跨越多个网段,由上百上千台主机组成。跨网段一方面可以分散某一个网段压力,另外,避免单个路由节点失效所带来的网络整体失效的问题。 不要引入欺骗,篡改等概念,因为系统不具备这个功能,代码都是固定的,都系统设计人员确定。

Acceptor接收两个东西,一个是预约,另一个是提议,预约表示acceptor在接受请求之前,需要请求预约,一旦accept,则不可毁约。

为什么要用n的大小拒绝呢?先到先accept不行吗?

这个n应该是唯一的序号,是proposer的编号,有唯一性,不可改。

一致性算法并不是只有paxos这种唯一解,修改其中一个步骤,都可以成为另外一个算法。

当一个 Proposer 接收到超过一半 Acceptor 的request时,就可以发送proposal。

Acceptor 接收到接受请求时,如果序号大于等于该 Acceptor 承诺的最小序号,那么就发送通知给所有的 Learner(学习者)。当 Learner 发现有大多数的 Acceptor 接收了某个提议,那么该提议的提议值就被 Paxos 选择出来。

n的作用,n越大越有优势

如果learner过多,存在一致性问题?

在某一个时间点,learner如何知道有多少台acceptor?由于accept收到大n会向learner反馈,那么会不会有大量这样的反馈,如何确定过半?可能多个提议超过一半!

https://zhuanlan.zhihu.com/p/44997221

Copyright © iovi.com 2017 all right reserved,powered by GitbookLast Modification: 2019-12-05 13:22:54

results matching ""

    No results matching ""