Paxos算法解决的问题是一个分布式系统如何就某个值(决议)达成一致。这个算法被认为是同类算法中最有效的.Paxos与MySQL相结合可以实现在分布式的MySQL数据的强一致性。
Paxos要解决的问题,是分布式系统中的一致性问题。那么到底什么是“分布式系统中的一致性问题”呢?在分布式系统中,为了保证数据的高可用,通常,我们会将数据保留多个
副本(复制品),这些副本会放置在不同的物理的机器上。副本要保持一致,那么,所有副本的更新序列就要保持一致。因为数据的增删改查操作一般都存在多个客户端并发操作,
到底哪个客户端先做,哪个客户端后做,更新顺序要保证。如果不是分布式,那么可以通过加锁的方法,谁先申请到锁谁就先操作,但这就存在单点问题.Paxos协议主要有两种用法:
一种用法是用来实现全局的锁服务或者命名和配置服务,例如谷歌胖乎乎的以及Apache管理员。另外一种用法是用它来将用户数据复制到多个数据中心,例如谷歌超大卖场以及谷歌扳手。
在Paxos算法中,主要有3种角色:
申请人:提议者
受体:决策者
学习者:最终决策学习者
实现的时候往往采用一组固定数目的服务器,每个服务器同时担任上述三个角色。
Paxos算法分为以下三个阶段:
1、准备阶段
(1)申请人向大多数受体发起提议(epochNo、价值)的准备请求。
(2)承兑人收到准备请求,如果epochNo比之前接收到的小,直接拒绝,如果epochNo比之前已经接收的大,就将已经接收到的epochNo最大的提案返回到申请人。
(3)申请人发起的提案至少要收到大多数以上的受体的准备应答后,才能进入接下来的接受阶段,否则需要重新进行准备阶段向大多数受体发起准备请求。
2、接受阶段:
(1)申请人收到大多数的受体的准备应答后,看受体是否已经有被接受的建议。如果没有已经接受的提议,就自己提出一个提议,发起接受请求;如果已经有被接受的提议,就从中选出epochNo最大的建议,发起对该提议的接受请求。
(2)承兑人收到请求后,如果该提案的epochNo比它最后一次应答准备请求的epochNo要大,那么就接受该请求,否则拒绝该请求。
3、学习阶段:
所有受体接受的提案要不断通知学习者,或者学习者主动去查询,一旦学习者确认提议被大多数的受体接受,那么表示这个建议的值被选中,学习者就可以学习这个建议的价值,同时自己的服务器上就不再受理Proposor的请求。
Paxos协议数据同步方式相对于基于传统1主N备的同步方式有啥区别?
一般情况下,传统数据库的高可用都是基于主备来实现,1主1备2个副本,主库崩溃后,通过哈工具来进行切换,提升备库为主库。在强一致场景下,复制可以开启强同步,甲骨文和Mysql都是类似的复制模式。但是如果备库网络抖动,或者崩溃,都会导致日志同步失败,服务不可用。为此,可以引入1主N备的多副本形式,我们对比都是3副本的情况,一个是基于传统的1主2备,另一种基于paxos的1主2备。传统的1主两备,进行日志同步时,只要有一个副本接收到日志并就持久化成功,就可以返回,在一定程度上解决了网络抖动和备库崩溃问题。但如果主库出问题后,还是要借助于哈工具来进行切换,那么哈切换工具的可用性如何来保证又成为一个问题。基于paxos的多副本同步其实是在1主N备的基础上引入了一致性协议,这样整个系统的可用性完全有3个副本控制,不需要额外的哈工具。而实际上,很多系统为了保证多节点哈工具获取主备信息的一致性,采用了动物园管理员等第三方接口来实现分布式锁,其实本质也是基于paxos来实现的。
Paxos要解决的问题,是分布式系统中的一致性问题。那么到底什么是“分布式系统中的一致性问题”呢?在分布式系统中,为了保证数据的高可用,通常,我们会将数据保留多个
副本(复制品),这些副本会放置在不同的物理的机器上。副本要保持一致,那么,所有副本的更新序列就要保持一致。因为数据的增删改查操作一般都存在多个客户端并发操作,
到底哪个客户端先做,哪个客户端后做,更新顺序要保证。如果不是分布式,那么可以通过加锁的方法,谁先申请到锁谁就先操作,但这就存在单点问题.Paxos协议主要有两种用法:
一种用法是用来实现全局的锁服务或者命名和配置服务,例如谷歌胖乎乎的以及Apache管理员。另外一种用法是用它来将用户数据复制到多个数据中心,例如谷歌超大卖场以及谷歌扳手。
在Paxos算法中,主要有3种角色:
申请人:提议者
受体:决策者
学习者:最终决策学习者
实现的时候往往采用一组固定数目的服务器,每个服务器同时担任上述三个角色。
Paxos算法分为以下三个阶段:
1、准备阶段
(1)申请人向大多数受体发起提议(epochNo、价值)的准备请求。
(2)承兑人收到准备请求,如果epochNo比之前接收到的小,直接拒绝,如果epochNo比之前已经接收的大,就将已经接收到的epochNo最大的提案返回到申请人。
(3)申请人发起的提案至少要收到大多数以上的受体的准备应答后,才能进入接下来的接受阶段,否则需要重新进行准备阶段向大多数受体发起准备请求。
2、接受阶段:
(1)申请人收到大多数的受体的准备应答后,看受体是否已经有被接受的建议。如果没有已经接受的提议,就自己提出一个提议,发起接受请求;如果已经有被接受的提议,就从中选出epochNo最大的建议,发起对该提议的接受请求。
(2)承兑人收到请求后,如果该提案的epochNo比它最后一次应答准备请求的epochNo要大,那么就接受该请求,否则拒绝该请求。
3、学习阶段:
所有受体接受的提案要不断通知学习者,或者学习者主动去查询,一旦学习者确认提议被大多数的受体接受,那么表示这个建议的值被选中,学习者就可以学习这个建议的价值,同时自己的服务器上就不再受理Proposor的请求。
Paxos协议数据同步方式相对于基于传统1主N备的同步方式有啥区别?
一般情况下,传统数据库的高可用都是基于主备来实现,1主1备2个副本,主库崩溃后,通过哈工具来进行切换,提升备库为主库。在强一致场景下,复制可以开启强同步,甲骨文和Mysql都是类似的复制模式。但是如果备库网络抖动,或者崩溃,都会导致日志同步失败,服务不可用。为此,可以引入1主N备的多副本形式,我们对比都是3副本的情况,一个是基于传统的1主2备,另一种基于paxos的1主2备。传统的1主两备,进行日志同步时,只要有一个副本接收到日志并就持久化成功,就可以返回,在一定程度上解决了网络抖动和备库崩溃问题。但如果主库出问题后,还是要借助于哈工具来进行切换,那么哈切换工具的可用性如何来保证又成为一个问题。基于paxos的多副本同步其实是在1主N备的基础上引入了一致性协议,这样整个系统的可用性完全有3个副本控制,不需要额外的哈工具。而实际上,很多系统为了保证多节点哈工具获取主备信息的一致性,采用了动物园管理员等第三方接口来实现分布式锁,其实本质也是基于paxos来实现的。
