私は、多くの人が自由に描くことができる共同キャンバスや特定のシェイプツールを実装しようとしています。 ServerはNode.jsとクライアントでAngular1-jsを使って開発されました（そして、私はどちらもかなり新しいです）。 すべてのユーザーに常に同じものを表示するには、コンセンサスアルゴリズムを使用する必要があります。Node.jsのコンセンサスアルゴリズム
私は、正しいチュートリアルの使用方法が見つからないため、深刻な問題があります。私はPaxosの実装を見て勉強してきましたが、実際にはRaftが非常に使用されているようです。
提案がありますか？とても感謝しております。
Understanding Paxosをお試しください。これは、学術的な聴衆ではなく、ソフトウェア開発者を対象としています。この特定のアプリケーションについては、この記事で参照されているMulti-Paxos Example Applicationにも興味があります。コンセンサスアルゴリズムの背後にあるコンセプトを説明するのに役立つと同時に、このアプリケーションに必要なものとほぼ同じように思えます。ラフトやほとんどのマルチパクソスのデザインは、単純な一貫性を超えて対処する新しい一連の問題を生み出す蓄積された歴史の過多に悩まされがちです。最初のプロトタイプは、各更新時に図面のフルステートの送信を容易に処理し、履歴アプリケーションの問題を完全に無視することができます。ネットワークのオーバーヘッドを削減するために、後で最適化を行うことができます。
分散システムの作成は簡単な作業ではありませんので、最初から実装するのではなく、既存の強固に一貫したものを使用することをお勧めします。通常の容疑者はzookeeper,consul,etcd,atomix/copycatです。それらのいくつかはnodejsクライアントに提供：
私は個人的にかかわらず、nodejsでそれらのいずれかを使ったことがないので、私は勝ちましたクライアントの成熟度に関するコメントはありません。
あなたがコンセンサスを自分で実装することを主張する場合、ラフトは理解しやすいはずです。論文は驚くほどアクセシブルです。https://raft.github.io/raft.pdf。彼らはまた、いくつかのnodejs実装を持っていますが、私はそれらを使用していないので、特定のものを推薦するのは難しいです。 Gaggle readmeには例があり、その使用方法を記載したskiff has an integration testがあります。
ここで必要なのは、分散したコンセンサスなのかどうかはわかりません。複数のクライアントと1台のサーバーがあるようです。おそらく、集中データストアを使用することができます。問題のドメインは本当に分散されているわけではありません.FIFO（同じホワイトボードに複数の人が書いていると想像して、最後のものが勝ったと想像してください）に従ってサーバがサーバに受信したときにシェイプを重なり合わせることができます。課題は、既存の図形を同時に変更することです。多分、最終的な/最初の変更の勝利などに置き換えることができます。
ここでもう1つ興味深いのは、Conflict-free Replicated Data Types — CRDTです。 githubの人々はそれらを使って共同で "ペア"プログラミングをアトミックに実装しました。 the atom teletype blog postを参照してください。また、their implementationが役に立つかもしれません。共同編集は、解決しようとする問題とまったく同じようです。
これが役に立ちます。
[1] jepsenシリーズhttps://jepsen.io/analysesを参照してください。ここで、Kyle Kingsburyはデータストアの配信のさまざまな失敗条件をテストします。
実際、EC2を動作させるには、サーバをEC2に複製する必要があります。 – JackLametta
WebGL（Three.js）で '
@AlekseySolovey 、コンセンサスの部分には問題があります。あなたはスキフが使われているチュートリアルやプロジェクトを知っていますか？ – JackLametta
ホイールを改造しないでください。あなたは一貫性を持って集中した場所にデータを保存したいと思っています。これをデータベースといいます。いくつかの新しいデータ、接続されたクライアントに出戻ってそれを送信し、店舗を取得し、どこかにいくつかのバックエンドサービスに彼らの行動を送信するためにクライアントを知らせる、バックエンドサービスは、既存のデータ+これらを取ります。 – GManNickG