标签: paxos

有人可以简单解释一下Operational Transform和CRDT之间的主要区别吗？

据我所知,这两种算法都允许数据在分布式系统的不同节点上收敛而不会发生冲突.

在哪个用例中你会使用哪种算法？据我所知,OT主要用于文本,CRDT更通用,可以处理更高级的结构吗？

CRDT比OT更强大吗？

我问这个问题是因为我试图了解如何为HTML文档实现协作编辑器,并且不确定首先查看哪个方向.我看到了ShareJS项目,以及他们尝试在contenteditables元素上的浏览器上支持富文本协作.在ShareJS中我没有看到任何使用CRDT的尝试.

我们也知道Google Docs正在使用OT,它在富文档的实时版本中运行良好.谷歌是否选择使用OT,因为CRDT当时并不为人所知？或者它今天也是一个不错的选择？

我也有兴趣了解其他用例,比如在数据库上使用这些算法.Riak似乎使用CRDT.OT也可用于同步数据库的节点,是Paxos/Zab/Raft的替代品吗？

什么时候使用像CRDT而不是paxos或筏这样的东西是个好主意？

我试图理解paxos和两阶段提交之间的区别,作为在多台机器之间达成共识的手段.两阶段提交和三阶段提交很容易理解.似乎3PC解决了在2PC中会阻塞的故障问题.所以我真的不明白Paxos正在解决什么问题.任何人都能说明Paxos究竟解决了什么问题吗？

类似Dynamo的数据库(例如Cassandra)可以通过仲裁来强制执行一致性,即一些同步写入的副本(W)和一些要读取的副本(R)应该以W + R> N的方式选择N是复制因子.另一方面,像Zookeeper这样的基于PAXOS的系统也被用作一致的容错存储.

这两种方法有什么区别？PAXOS是否提供W + R> N架构未提供的保证？

有人可以给我一份Paxos的实际用例列表.这是需要达成共识的真正问题,是更大问题的一部分.

以下是Paxos的用例吗？

假设有两个客户在扑克服务器上互相玩扑克.扑克服务器被复制.我对Paxos的理解是,它可以用来保持代表当前扑克之手的内存数据结构的一致性.也就是说,确保所有副本具有完全相同的内存状态.

但为什么Paxos必要？假设需要处理新卡.如果一切正常,运行相同代码的每个副本将生成相同的卡.为什么客户端不能从所有复制的服务器请求最新状态,并选择最多出现的卡.因此,如果一台服务器出现错误,客户端仍然可以通过选择多数来获得正确的状态.

我读过Lamport 关于Paxos 的论文.我也听说过,由于性能原因,它在实践中并没有太多用处.在分布式系统中,通常使用哪些算法来达成共识？

我正在使用维基百科中提供的文档在集群模拟器应用程序中实现Paxos .不幸的是,它留下了几个可以解释的门,并没有提供关于关键实施问题的大量信息.目前还不清楚和不完整.

• 假设一个簇分为3个区域,每个区域包含3个节点(总共= 9个节点).如果地区之间的沟通中断,会发生什么？任何领导者都无法达到法定人数(即5).

Paxos不会进入无限循环吗？我想如果一个人无法与至少一个法定数量的节点通信,就不应该发起Paxos.

• 1B阶段:" 如果提案数N大于以往任何建议时,则每个接受者承诺不接受建议小于N,并把它最后接受了价值为这种情况下,以投保人 ".

什么是"它接受的最后价值"？来自提议者的任何先前提案编号是什么？在这种情况下,'实例'究竟是指什么？

• 在阶段1a:是否包含与准备消息达成一致的值,或者是否延迟到接受!信息？或者它确实重要？

• 在阶段2a:' 如果任何接受者已经接受了值,则领导者必须选择具有最大提议号N '的值.

这里有什么价值？是提案编号吗？我不相信,但这句话不清楚.

• 在阶段2a:'否则,提议者可以自由选择任何值'.这是什么意思？什么价值？对于提案号码？

• Paxos似乎依赖于增加的N(提案号)值来运作？它是否正确？

• 维基百科条目不讨论节点在开始参与Paxos之前应该设置的初始值.这些是什么？

PS:我没有足够的声誉来创建'Paxos'标签(任何志愿者？)

有人能给我一个关于如何在分布式数据库中使用Paxos算法的真实示例吗？我已经阅读了许多关于Paxos的论文来解释算法,但没有一篇真正用实际例子来解释.

一个简单的例子可能是银行应用程序,其中一个帐户正在通过多个会话进行修改(即柜员存款,借记操作等).Paxos是否用于决定首先进行哪种操作？此外,Paxos协议的多个实例意味着什么？怎么用这个？基本上,我试图通过一个具体的例子而不是抽象的术语来理解这一切.

阶段2.(a)如果提议者从大多数接受者收到对其准备请求(编号为n)的响应,则它向每个接受者发送一个接受请求,用于编号为n且值为v的提议,其中v为响应中编号最高的提案的值,如果响应未报告任何提议,则为任何值.

如论文中所述,

提议者通过向一组接受者发送提议被接受的请求来发布提议.(这不一定是响应初始请求的同一组接受器.)"

但正如我的理解,如果我们将第2阶段改为:(a):

如果提议者从大多数接受者收到对其准备请求(编号为n)的响应,则它向任意一组多数接受者发送一个接受请求,该请求用于编号为n且值为v的提议,其中v是该值的值.答复中编号最高的提案,如果答复未报告提案,则为任何值.

算法将失败,以下是一个例子.考虑到共有3个接受者ABC.我们将使用X(n:v,m)来表示接受者X的状态:提议n:v是X接受的最大编号提议,其中n是提议编号,v是提议的值,m是X曾经回复的编号最大的准备请求的编号.

1. P1向AB发送'准备1'
2. AB都承诺不接受任何编号小于1的请求.现在状态为:A( - : - ,1)B( - : - ,1)C( - : - , - )
3. P1接收响应,然后卡住并且运行得非常慢
4. P2向AB发送'准备100'
5. AB都承诺不接受任何编号小于100的请求.现在状态为:A( - : - ,100)B( - : - ,100)C( - : - , - )
6. P2接收响应,选择值b并将"接受100:b"发送到BC
7. BC接收并接受接受请求,状态为:A( - : - ,100)B(100:b,100)C(100:b, - ).请注意,已选择提案100:b.
8. P1恢复,选择值a并向BC发送'accept 1:a'
9. B不接受它,但C接受它,因为C从未承诺任何东西.状态是:A( - : - ,100)B(100:b,100)C(1:a, - ).选择的提案被放弃,Paxos失败了.

我在这里错过了吗？谢谢.

在阅读了paxos和筏纸之后,我有以下困惑:paxos论文仅描述了单日志条目的共识,这相当于筏算法的领导者选举部分.在木筏领导者选举中,paxos的方法优于简单的随机超时方法有什么优势？