如何解决Raft 在协同编辑方面与 CRDT 相比如何?
我试图了解当状态只是一个可以包含数组的 JSON blob 时,Raft 在协作编辑方面有多好。
我的直觉是,Raft 是为安全而构建的,而 CRDT 是为速度而构建的(牺牲可用性)。想了解更多关于使用 Raft 进行协作编辑的可行性的意见。
解决方法
首先,Raft 要求所有写入必须通过同一个 actor(leader)并且在提交之前以相同的顺序存在。这意味着:
- 如果您无法从您的机器访问当前领导者,您将无法提交任何写入。
- 为了确保总订单,您需要等待领导者的提交确认,这可能需要超过 1 次往返。对于协作编辑案例,这意味着削弱应用程序的响应能力,因为在远程服务器确认前一个更新之前,您无法提交下一个更新(例如按键)。
- 如果您的领导者将失败,您需要等到下一个更新可以提交的进一步更新之前。
- 有一组特定的冲突解决问题,Raft 并不真正知道如何处理。最简单的例子:两个人在同一个位置的光标下打字——你很容易得到他们两个人的文本交错(例如,在同一个位置 A 写 'hello',B 写'world',因此您可以将文本作为这些的任意排列,例如 'hwelolrldo')。
除了其他问题 - 例如成员资格和重新交付 - Raft 本身并不能为上述问题提供有价值的解决方案。你需要自己解决它们。
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。