あなたには大きな問題があります。あなたが問題について考えている方法は、より大きな問題だと思います。いくつかの基本を見ていきましょう。
クラスタリングは、「象を食べる」問題のように、大きな問題を解決するために使用されます。この問題を解決するには、巨大な口を持つユニークで大きな捕食者を設計します。しかし、歴史と古生物学は、大型の捕食者は容易に維持できないことを示しています (環境への負担が大きい)。
したがって、問題を解決するには、より強力なサーバーを使用できます.
または、クラスタリングを使用できます。
クラスタリングは、「象を食べる」問題をまったく異なる方法で解決します。巨大な口を持つユニークな巨大な捕食者を送って象を食べるのではなく、分散および共有処理の概念を使用して、一度に一口ずつ食べます。適切に行うと、アリは象を食べることができました。それらが十分にあり、状況が正しい場合。
しかし、私の例では、アリは非常に小さいことに注意してください... 1 匹のアリが象全体を運ぶことは決してありません。すべてのアリが一緒に機能する場合、象全体を運ぶことができますが、同時実行性とロックの問題が発生します (アリを調整する必要があります)。
アリは、これに対処するためのはるかに優れた方法を示してくれました。彼らは象の一部を取り、問題を小さなチャンクで扱います。
システムで、ノード間でデータを同期する方法を尋ねます...私の質問はなぜですか? データを同期している場合はミラーリングしているため、問題はさらに大きくなります (象のクローンを作成していますが、元のデータしか食べられません)。
問題の解決策は、解決策を再考し、問題をより小さな部分に分解できるかどうかを確認することです。
Akka と Actor パターンでは、問題に対処する最善の方法は、より小さな「プロセス」 (単一のアリ) を使用することです。プロセス自体はほとんど役に立ちませんが、大規模に使用すると非常に強力になります。アーキテクチャが適切に行われると、アリに火炎放射器を持って行ってもアリを倒すことはできないことに気付くでしょう...より多くのアリが来て、彼らは問題に取り組み続けます.
データのコピーと同期はソリューションではなく、クラスタリングです。データを取得し、それを 1 匹のアリに与えることができるポイントまで分解する必要があります。これができれば、Akka を使用できます。このアプローチがばかげていると思われる場合、Akka は適していません。
しかし、これを考慮してください...あなたは明らかにデータベースのバックエンドに懸念を抱いています-IOを増やして単一障害点を導入したくないのです。私はあなたに同意しなければなりません。しかし、物事を再考する必要があります。単一障害点を取り除くためにデータベース ミラーリングを使用することもできますが、これではボトルネックが解消されないことは間違いありません。では、ミラーリングによって単一障害点が取り除かれたとしましょう。では、ボトルネック部分に取り組みましょう。
データをアリが処理できるほど小さなチャンクに分割できる場合は、データが変更されたときにのみデータベースに報告するようにアリに指示することをお勧めします...初期化時に一度読み取ることができます（バックエンドが必要です）電気はすぐに失われる可能性があります...どこかに保存する必要があります)しかし、アリに変更されたデータのみを保持するように指示すると、方程式からすべてのクエリが削除され、負荷がどこに劇的にシフトしますから来ています。処理する更新、挿入、および削除のみがあれば、ランドスケープ全体がはるかに単純になります。
クラスタリングが解決策になるはずですが、それはミラーの概念を頭から取り除くことができる場合に限られます。
クラスター ノードはクラッシュする可能性があり、クラッシュする可能性があります。ノード/ワーカープロセス/アリのクラッシュまたは損失に対処する場合にのみ、データをリロードする必要があります...
幸運を祈ります... あなたは、ソフトウェア工学の学位を持つ人々が解決に失敗するのを見てきました。