什么时候使用CRDT代替paxos或raft？
答案 0 :(得分：34)
如果您可以使用CRDT之类的东西，请执行此操作。你应该得到更好的表现。它还支持有趣的用例，例如脱机工作，然后再合并。然而，并不总是能够设计出CRDT适合您的东西。在这种情况下，paxos可以为您解决难题。
但即使您决定使用paxos，通常也应该通过paxos算法直接限制工作量。相反，出于性能原因，您希望为主要选举等必要操作保留paxos，然后让复制的主设置处理大多数决策。 （在高吞吐量环境中，主服务器可能会执行某些操作，例如将特定分片的责任委派给特定的子级，这些子级会相互复制。不要让主服务器成为瓶颈......）
也就是说，声称你会挥动paxos的魔杖比在实践中实际执行它更容易。有鉴于此，您可能会发现http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en/us/archive/chubby-osdi06.pdf是对现实世界paxos实施可能遇到的困难的有趣描述。
答案 1 :(得分：14)
答案 2 :(得分：4)
CRDT和Paxos有不同的目标，并在不同的情况下使用。 它们的共同之处在于它们可以帮助程序员处理并发/复制。 CRDT是将发生并发更新的数据类型。 Paxos是一种协议，通过强制执行总订单来强制执行它们。 让我们更详细地看一下。
假设我们有一个复制集，可以在两个不同的地方复制。
使用Paxos 可确保每个副本以相同的顺序执行对该集的写入。更一般地说，它保证所有副本都同意集合的状态如何发展。
例如，如果你有user1在replica1上执行update1，将元素1添加到复制集，同时user2执行update2，在replica2添加element2，Paxos将使这些更新的给定订单上的副本达成一致，或者可能同意选择两个更新中的一个并丢弃第二个更新，具体取决于您如何使用它以及您想要实现的目标。 如果Paxos结果是，例如，update1在update2之前，则每个副本将按该顺序更新集合。 因此，与这些更新同时读取集合的用户可以观察到，无论他们在何处（在哪个副本上）读取，只能观察集合的以下状态（假设集合在开始时为空）：
{}（空集）
{元素1}
{element1，element2}
此外，只能按顺序看到这些状态，这意味着一旦集合的状态为{element1，element2}（在每个副本），后续读取都不会返回{}或{element1}。
积极的一面：这个集合很容易理解，因为它相当于一个没有被复制的集合。
否定方： 不可用：如果副本无法相互通信（网络分区），则无法更新您的集，因为无法达成协议。 低性能，高延迟：协议要求在回复客户端之前同步副本。这会导致与副本之间的延迟成比例的延迟。
CRDT的保证较弱。 CRDT集不等同于顺序单拷贝集。它假设没有关于如何更新副本的协议或总命令。
CRDT保证如果集合的两个副本都看到相同的更新（无论它们看到它们的顺序如何），那么它们将呈现相同的状态;复制品将汇聚。
在我们同时执行更新的两个用户的示例中，不运行Paxos以对集合执行命令的系统（这例如，在最终或因果一致性下发生）将允许replica1添加element1而replica2正在添加element2
所以，replica1的状态为：{element1}
，replica2的状态为：{element2}
此时，复制品出现了分歧。 之后，当副本同步时，他们将交换他们的更新，最终展现出这种状态：
replica1上的状态为：{element1，element2}
replica2上的状态为：{element2，element1}
此时，复制品已经收敛。
与这些更新同时读取集合的用户可以根据他们读取的位置（在哪个副本上）观察集合的以下状态（假设集合在开始时为空）：
{}（空集）
{element1}（如果他们从replica1读取）
{element2}（如果他们从replica2读取）
{element1，element2}
{element2，element1}
否定方面：这个集很难推理，因为它显示了顺序集中不会出现的状态。在我们的示例中，我们仅观察到两个并发添加到集合的情况，这很简单。并发添加和删除更复杂有许多数据类型具有不同的问题：
A comprehensive study of Convergent and Commutative Replicated Data Types
积极的一面： 高可用性：如果副本无法相互通信（网络分区），则可以更新您的设置。副本将在连接时同步。 高性能，低延迟：在回复客户端后，副本会立即回复客户端并在后台进行同步。
答案 3 :(得分：3)
CRDT Treedoc示例存在缺陷。当两个系统使用相同的密钥同时插入时，每个节点都需要消除歧义。
在此之后，系统不再可能在具有相同键但具有不同歧义的条目之间插入，因为这需要系统插入另一个相同的键但控制消歧器排序。消歧者并不密集，所以这并不总是可行的。如果消歧者是另一棵树，你解决了一个问题，但是需要另一个冲突解决机制，深度进一步下降......等等。
这个未提及的问题，加上您需要进行两阶段提交以整理元数据这一事实让我觉得CRDT仍在进行中。
答案 4 :(得分：1)
我们有多个指标：
我的建议是，当副本彼此不远时（例如，在数据中心内），我们应该使用Paxos，并且当网络分区是正常的（例如，断开连接的移动设备）时使用CRDT。
答案 5 :(得分：1)
评论@btilly的回复：
本主题中的问题涉及不同的一致性模型以及设计模式：
CRDT和Paxos是非常不同的东西，必须根据您的架构要求来决定使用情况。我认为处理它的最佳方法是审查成功应用这些算法的用例。
使用模式：
CRDT可用于客户端（即移动设备）和服务器之间的数据同步，实时协作编辑，dist-db实现中的值同步以及最终一致性良好的所有其他情况。
PAXOS主要用于支持系统基础设施（即Chubby）的专有系统，或用于在BigTable，Datastore，Spinnaker，Spanner等分布式数据库系统中实现同步。
RAFT在ETCD，Consul等OSS基础设施项目中更受欢迎......
（不记得CockroachDB和TiDB基于什么）
还有一个BFT，但用得少。
P.S。 PAXOS！= ZooKeeper。 ZooKeeper使用称为ZAB的不同算法，不是复制状态机，而是使用单个编写器和轻松读取模型复制快照机器。 Google的Chubby基于Paxos，但其专有。
p.s.s。有趣的是PAXOS这些年来如何发展。在过去的20年中，发明了许多变体，处理边缘情况，仲裁大小和集群重新配置的各种优化。
答案 6 :(得分：-2)
每当合适时。然而，PaxOS并不是那么糟糕，因为它的吞吐量通常与CRDT相同，更不用说可靠性要高得多（CRDT可能导致状态丢失），并且它的延迟也不是那么糟糕，因为它只需要大多数副本的回复而不是所有。