我正在尝试实现一个协作画布,许多人可以在其中自由绘制或使用特定的形状工具。服务器是在 Node.js 中开发的,客户端是使用 Angular1-js 开发的(我对它们都很陌生)。我必须使用共识算法来向所有用户显示始终相同的内容。
由于找不到合适的使用教程,因此我遇到了严重的麻烦。我一直在寻找和研究 Paxos 的实现,但似乎 Raft 非常实用。
有什么建议么?我真的很感激。
编写分布式系统并非易事[1],因此我建议使用一些现有的强一致性系统,而不是从头开始实施。通常的嫌疑人是zookeeper,consul,etcd,atomix/copycat。其中一些提供 nodejs 客户端:
我个人从来没有在 nodejs 中使用过它们,所以我不会评论客户端的成熟度。
如果你坚持自己实现共识,那么 raft 应该更容易理解——这篇论文出乎意料地可以访问https://raft.github.io/raft.pdf。他们也有一些 nodejs 实现,但同样,我没有使用它们,所以很难推荐任何特定的实现。Gaggle 自述文件包含一个示例,skiff 有一个集成测试,记录了它的用法。
退后一步,我不确定分布式共识是否是您所需要的。好像您有多个客户端和一个服务器。您可能可以使用集中式数据存储。问题域并不是真正分布的——当服务器根据 FIFO 接收形状时,形状可以一个一个叠加在另一个之上(想象多个人在同一个白板上书写,最后一个获胜)。挑战在于对现有形状的并发修改,也许您可以回退到最后/第一个更改获胜或类似的东西。
在这里探索的另一个有趣的途径是无冲突的复制数据类型——CRDT。github 上的人们使用它们在 atom 中实现协作“结对”编程。请参阅atom teletype 博客文章,它们的实现也可能有用,因为协作编辑似乎正是您试图解决的问题。
希望这可以帮助。
[1] 查看 jepsen 系列https://jepsen.io/analysiss,其中 Kyle Kingsbury 测试了分布式数据存储的各种故障条件。
尝试阅读理解 Paxos。它面向软件开发人员而不是学术受众。对于这个特定的应用程序,您可能还对Multi-Paxos 示例应用程序感兴趣文章引用的。它的目的是帮助说明共识算法背后的概念,听起来它几乎正是你在这个应用程序中所需要的。Raft 和大多数 Multi-Paxos 设计往往会陷入过多的累积历史,这会产生一系列新的问题来处理,而不仅仅是简单的一致性。初始原型可以轻松处理在每次更新时发送绘图的完整状态并完全忽略历史问题,这就是示例应用程序所做的。以后可以进行优化以减少网络开销。