Raft 在协同编辑方面与 CRDT 相比如何？

问题描述

我试图了解当状态只是一个可以包含数组的 JSON blob 时，Raft 在协作编辑方面有多好。

我的直觉是，Raft 是为安全而构建的，而 crdt 是为速度而构建的（牺牲可用性）。想了解更多关于使用 Raft 进行协作编辑的可行性的意见。

解决方法

首先，Raft 要求所有写入必须通过同一个 actor（leader）并且在提交之前以相同的顺序存在。这意味着：

1. 如果您无法从您的机器访问当前领导者，您将无法提交任何写入。
2. 为了确保总订单，您需要等待领导者的提交确认，这可能需要超过 1 次往返。对于协作编辑案例，这意味着削弱应用程序的响应能力，因为在远程服务器确认前一个更新之前，您无法提交下一个更新（例如按键）。
3. 如果您的领导者将失败，您需要等到下一个更新可以提交的进一步更新之前。
4. 有一组特定的冲突解决问题，Raft 并不真正知道如何处理。最简单的例子：两个人在同一个位置的光标下打字——你很容易得到他们两个人的文本交错（例如，在同一个位置 A 写 'hello'，B 写'world'，因此您可以将文本作为这些的任意排列，例如 'hwelolrldo'）。

除了其他问题 - 例如成员资格和重新交付 - Raft 本身并不能为上述问题提供有价值的解决方案。你需要自己解决它们。