Paxos的通俗理解以及在数据库高可用上的使用
副标题[/!--empirenews.page--]
《Paxos的通俗理解以及在数据库高可用上的使用》要点:
1、为什么需要PaxosPaxos要解决的问题,是分布式系统中的一致性问题.那么到底什么是“分布式系统中的一致性问题”呢?在分布式系统中,为了保证数据的高可用,通常,我们会将数据保留多个副本(replica),这些副本会放置在不同的物理的机器上.副本要保持一致,那么,所有副本的更新序列就要保持一致.因为数据的增删改查操作一般都存在多个客户端并发操作,到底哪个客户端先做,哪个客户端后做,更新顺序要保证.如果不是分布式,那么可以通过加锁的方法,谁先申请到锁谁就先操作,但这就存在单点问题.Paxos协议主要有两种用法:一种用法是用来实现全局的锁服务或者命名和配置服务,例如Google Chubby以及Apache ZooKeeper.另外一种用法是用它来将用户数据复制到多个数据中心,例如Google Megastore以及Google Spanner. 以一个分布式的KV数据库为例,假设数据库对外提供2种操作Put和Get,具体架构如下: 在这样一个架构下,可以通过多台server组成集群来避免单点问题.我们需要解决的是3台server必须保持同步,也就是说,如果向集群发送请求Put(“a”,1)并成功,那么整个集群任意一台server必须含有(“a”,1).另外假设此时多个client并发访问集群,不同客户端的请求可能会落入到不同的server机器上,比如并发有Put(“b”,2)和Put(“c”,3),我们需要保证哪个客户端请求先做,哪个后做,保证更新顺序,这就是Paxos算法需要解决的问题. 2、Paxos算法我们先来简单描述一下Paxos算法,对算法本身有一个直观的认识,然后再结合后面的例子来进一步理解. 在Paxos算法中,主要有3种角色:
实现的时候往往采用一组固定数目的Server,每个Server同时担任上述三个角色. Paxos算法分为以下三个阶段: 1、Prepare阶段 (1)Proposer向大多数Acceptor发起Proposal(epochNo,value)的Prepare请求. (2)Acceptor收到Prepare请求,如果epochNo比之前接收到的小,直接拒绝;如果epochNo比之前已经接收的大,就将已经接收到的epochNo最大的Proposal返回到Proposer. (3)Proposer发起的Proposal至少要收到大多数以上的Acceptor的Prepare应答后,才能进入接下来的Accept阶段,否则需要重新进行Prepare阶段向大多数Acceptor发起Prepare请求. 2、Accept阶段: (1)Proposer收到大多数的Acceptor的Prepare应答后,看Acceptor是否已经有被接受的Proposal.如果没有已经接受的Proposal,就自己提出一个Proposal,发起Accept请求;如果已经有被接受的Proposal,就从中选出epochNo最大的Proposal,发起对该Proposal的Accept请求. (2)Acceptor收到请求后,如果该Proposal的epochNo比它最后一次应答Prepare请求的epochNo要大,那么就接受该请求;否则拒绝该请求. 3、Learn阶段: 所有Acceptor接受的Proposal要不断通知Learner,或者Learner主动去查询,一旦Learner确认Proposal被大多数的Acceptor接受,那么表示这个Proposal的Value被Chosen,Learner就可以学习这个Proposal的Value,同时自己的Sever上就不再受理Proposor的请求. 我喜欢通过例子来理解理论,理论源于生活,下面我以生活中的例子来进行该算法的描述. 假设一群驴友决定端午去旅游,驴友遍布全国各地,一共10人,为了能达成一致,这10个人另外找5个作为队长.5个队长之间相互不通信,只跟10个驴友发短信. 第一阶段(申请阶段),驴友发短信给5个队长,申请与队长进行沟通.队长在任何时刻只能与一个驴友沟通.发送的每条短信都带有时间,队长采用的原则是同意与短信发送时间最新的驴友沟通,如果出现更新的短信,则与短信更新的驴友沟通.至少大多数队长同意沟通了,这个驴友才能进入第二阶段实质性沟通. 第二阶段(沟通阶段),获得沟通权的驴友A收到队长们给他发的旅游地,可能有几种情况.
(编辑:源码门户网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |