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

Question

我正在尝试理解当状态只是一个可以包含数组的JSON blob时，Raft对于协作编辑有多好。

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

Answer 1

首先，Raft要求所有的写操作必须通过相同的参与者(领导者)，并且在提交之前以相同的顺序存在。这意味着：

1. 如果您没有从计算机访问当前leader的权限，您将无法提交任何写入。
2. 为了确保总订单，您需要等待leader的提交确认，这可能需要1次以上的往返。对于协作编辑情况，这意味着削弱应用程序的响应性，因为您无法提交下一次更新(例如，
3. 如果你的领导者将失败，你将需要等待，直到下一个被选举出来之前，任何进一步的更新可能是committed.
4. There's一组特定的冲突解决问题，该how并不知道如何处理。最简单的例子是:两个人在光标下同一位置打字--你很容易得到两个人的文本交错(例如。在相同的位置，A写'hello'，B写'world'，结果你可以有文本是这些的任何排列，例如。'hwelolrldo').

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