带你一步步走入Paxos的世界 -- 序列1

说起Paxos,很多人都知道,并且大家对它的看法基本都是“晦涩难懂”。除了Lamport那2篇鼎鼎大名的原生paper,网上文章也很多。但看来看去,总觉得“云山雾罩”,也不知道为什么要这么做,以及它到底能解决什么问题。

我觉得究其原因,一方面是很多Paxos的资料,都是在通过形式化的证明,去论证这个算法的正确性,自然艰深晦涩;另一方面,基于Paxos的成熟的工程实践也不多,大家讨论来讨论去,都不能落实到实践层面。

而本人也是经历了这样一个“迷茫”的过程,最终才一点点理解Paxos到底是什么。

而本序列,试图由浅入深的,从问题出发,一点点带领大家进入Paxos的世界。

这里写图片描述

一个基本的并发问题

先看一个最最基本的并发问题:假设我有一个KV存储集群,3个客户端,并发的向这个集群发送3个请求。请问,最后我去get(x)的时候,x应该等于几?

答案是:x = 1,或者 x = 3, 或者 x = 5 都是对的! 但 x = 4 ,就是错的!

因为从客户端角度来看,3个请求是并发的,但3个请求到达服务器的顺序是不确定的,所以最终3个结果都有可能。

这里有一个很关键的点:把上面的答案换一种说法,即如果最终集群的结果是x = 1。那么当client1发送x = 1的时候,服务器返回x = 1;当client2发送x = 5的时候,返回x=1;当client3发送x=7的时候,返回x=1。相当于client1的请求被接受了,client2/client3的请求被拒绝了!! 如果集群最终结果是x=3,或者x=5,是同样的道理!!

而这正是Paxos协议的一个特点。现在讲这个还是晦涩,后面我们再来提这个问题。
这里写图片描述

啥叫“时序”

把上面的问题进一步细化:假设这个KV集群,有3台机器,3台机器之间互相通信,把自己的值传播给其他机器,3个客户端分别向3台机器发送3个请求。

这里写图片描述

假设每个机器都把自己收到的请求,按日志存下来(包括从客户端来的请求和从其他node来的请求)。那请问:当这3个请求执行完之后,3台机器上面的日志,分别应该是什么顺序?

下面是正确的结果:不管顺序如何,只要3个机器上面的日志顺序是一样的,那结果就是正确的。比如第1种情况,3个机器上面,存储的日志顺序都是x=1/x=3/x=5,那么最终集群里面,x的值肯定等于5。其他情况类似。

很显然,总共有3的全排列,共6种情况。
这里写图片描述

而下面的情况就是错误的:机器1上面日志顺序是1,3,5,因此最终的值就是x=5;机器2是3,5,1,最终值是x=1;机器3是1,5,3,最终值是x=3。 3台机器上面关于x的值不一致。
这里写图片描述

通过这个简单的例子,我们就能对“时序”有一个直观的了解:虽然3个客户端是并发的,没有先后顺序,但到了服务器的集群里面,必须得保证3个机器上面,日志顺序是一样的,这就是所谓的“分布式一致性”。

Paxos解决什么问题

在上面的例子中,node1收到了x=1之后,复制给node2/node3;
node2收到x=3之后,复制给node1/node3;
node3收到x=5之后,复制给node1/node2。

客户端是并发的,3个node之间的复制也是并发的,那如何保证3个node最终的日志顺序是一样的呢?也就是上面说的那6种正确情况中的1种。

比如node1先收到客户端的x=1,之后收到node3的x=5,最后收到node2的x=3;
node2先收到客户端的x=3,之后收到node1的x=1,最后收到node3的x=5;
。。。

如何保证3个node上面存储的日志顺序一样呢???

而这正是Paxos要解决的问题!在接下来的序列中,我们将一步步讨论Paxos是如何解决这问题的!

最后

不同于很多Paxos的文章,本文并没有讲Paxos是什么,而是介绍了我们可以通俗理解的、一个并发问题的场景。如果你明白了这个场景,接下来在看Paxos,就会简单很多了。

猜你喜欢

转载自blog.csdn.net/chunlongyu/article/details/72834274