use*_*016 27 algorithm synchronization cassandra paxos apache-zookeeper
类似Dynamo的数据库(例如Cassandra)可以通过仲裁来强制执行一致性,即一些同步写入的副本(W)和一些要读取的副本(R)应该以W + R> N的方式选择N是复制因子.另一方面,像Zookeeper这样的基于PAXOS的系统也被用作一致的容错存储.
这两种方法有什么区别？PAXOS是否提供W + R> N架构未提供的保证？
Ham*_*pus 18
是的,Paxos提供类似Dynamo的系统及其读写仲裁不提供的保证.不同之处在于如何处理故障以及在写入期间发生的情况.写入成功后,两种系统的行为都相似.数据将被保存并随后可供读取(直到被覆盖或删除),依此类推.
写入和失败后会出现差异.直到您在向最终一致的系统写入内容时从W节点获得成功答案,然后数据可能已写入某些节点而不是其他节点,并且无法保证整个系统同意当前值.如果此时尝试读回数据,则某些客户端可能会返回新数据并返回一些旧数据.换句话说,系统不是立即一致的.这是因为这些系统中的节点之间的写入不是原子的.通常有机制来"治愈"这样的不一致性,并且"最终"系统将再次变得一致(即,读取将再次始终返回相同的值,直到写入新内容为止).这就是为什么它们通常被称为"最终一致"的原因.可以(并且将会)出现不一致的情况,但最终会对它们进行处理和协调.
使用Paxos,可以跨节点使写入成为原子,因此可以避免节点之间的不一致.Paxos算法可以保证非故障节点在任何时间点都不会对写入结果产生不同意见.无论是在任何地方还是在任何地方都能成功.在任何时候都不会有任何不一致的读取(如果它被正确实现并且当然所有假设都成立).然而,这需要付出代价.主要是,当例如太多节点(或它们之间的通信)不起作用时,系统可能需要延迟一些请求并且不可用.这是确保没有给出不一致的答复所必需的.
总结一下:主要区别在于类似Dynamo的系统可以在写入期间或失败后返回不一致的结果一段时间(但最终会从中恢复),而基于Paxos的系统可以保证从来没有任何这样的不一致不可用和延迟请求.
Ezr*_*och 13
Paxos和W + R> N法定人数试图解决略有不同的问题.Paxos通常被描述为复制状态机的一种方式,但实际上它更像是一个分布式日志:写入日志的每个项都获得一个索引,不同的服务器最终拥有相同的日志项+它们的索引.(复制状态机可以通过将状态机的输入写入日志来实现,并且每个服务器根据其索引在约定的输入上重放状态机).您可以在我在这里写的博客文章中阅读更多关于Paxos的信息.
W + R> N仲裁解决了在多个服务器之间共享单个值的问题.在学术界,它被称为"共享寄存器".共享寄存器有两个操作:读和写,我们希望读返回前一次写的值.
因此,Paxos和W + R> N法定人数存在于不同的域中,并且具有不同的属性(例如,Paxos保存有序的项目列表).但是,Paxos可用于实现共享寄存器,W + R> N仲裁可用于实现分布式日志(尽管效率非常低).
综合以上所述,有时候W + R> N的法定人数没有以"完全强健"的方式实施,因为它需要不止一次通信.因此,在期望低延迟的系统中,它们的W + R> N仲裁的实现可能提供较弱的属性(例如,可以共存存在冲突的值).
综上所述,理论上,Paxos和W + R> N可以实现相同的目标.实际上,这将是非常低效的,并且每个对于稍微不同的东西更好.更实际的是,W + R> N并不总是完全实现,因此为速度划分了一些一致性属性.
更新:Paxos支持非常一般的故障模型:消息可能被丢弃,节点可能崩溃并重新启动.W + R> N仲裁方案具有不同的实现,其中许多假设不太普遍的失败.因此,两者之间的差异还取决于对所支持的可能故障的假设.
Paxos实现起来非常重要,而且价格昂贵,许多使用它的系统也使用提示,或者我们仅用于领导者选举等等.但是,它确实在出现故障时保证了一致性 - 当然要受其特定故障模型的限制.
我看到的第一个基于仲裁的系统假设某种领导者或事务基础结构可确保足够的一致性,您可以信任仲裁机制的工作原理.这个基础设施很可能是基于Paxos的.
看一下https://cloudant.com/blog/dynamo-and-couchdb-clusters/这样的描述,似乎Dynamo 不是基于保证其仲裁系统一致性的基础设施 - 所以它非常聪明或者偷工减料？根据http://muratbuffalo.blogspot.co.uk/2010/11/dynamo-amazons-highly-available-key.html,"Dynamo系统强调可用性,以牺牲一致性.摘要读取"Dynamo牺牲一致性实际上,后来很明显Dynamo甚至在没有失败的情况下牺牲了一致性:Dynamo可能在存在多个并发写请求时变得不一致,因为副本可能由于多个协调器而分歧.(结束语)
因此,在Dynamo中实现的法定数量的情况下,Paxos提供了更强的可靠性保证.
正如其他答案中提到的，在 R+W > N 系统中，写入在所有节点上都不是原子的，这意味着当写入正在进行时（或写入失败期间），一些节点将具有较新的值和一些较旧的值。以 n=3、r=2 和 w=2 的系统为例。为了清楚起见，我们假设 3 个节点分别命名为 A、B 和 C。考虑以下场景：写入正在进行；写入正在执行。节点 A 已更新，而 B 和 C 仍在接收更新值。从 A 和 B 读取的客户端将看到较新的值（使用版本向量解析或最后写入获胜），从 B 和 C 读取的客户端将看到旧值。这种类型的读取不被认为是可线性化的。使用适当的线性化系统（例如 Paxos 或 Raft）不会出现此类问题。