接続されたクライアントに関する情報を共有できるようにする必要がある、すべてWANリンク（中程度の帯域幅、より高い遅延）を介して接続された少数のサーバーがあります。各クライアントは、「メッシュ」内の任意のサーバーに接続できます。各サーバーがホストおよび更新できる、ある種の分散データベースを探しています。各サーバーが長期間オフラインになっている場合は、各サーバーが現在の状態で更新できることが重要です。
何も見つからない場合は、すべてのサーバーが挿入できるMySQLDBをホストするサーバーを選択することもできます。しかし、可能であれば、これを単一障害点として削除したいと思います。（およびスレーブをマスターに昇格させることに関連するダウンタイム）
以前に使用したことがあり、推奨するシングルマスターの分散データストアはありますか？
いずれかのソリューションにPythonインターフェイスがある場合に最も役立ちます。
Pythonのmultiprocessing.Managerオブジェクトを見たことがありますか？
Manager分散データベースを維持するためのロジックを追加する必要があります（たとえば、新しいマスターの選択、冗長性、および必要な属性）。これは、オブジェクトを拡張して独自のオブジェクトを実装することで簡単に実行できますProxyが、前述のモジュールが処理します。すべての同期とデータ送信。
このように、分散データベースを使用する代わりに、メッシュはPythondictまたは複雑なデータ型Managerを共有し、接続されたプロキシと共有するようにオブジェクトに指示します。
doozerd projectを見てください。geventベースのPython クライアントがあります。
サーバーが一定時間オフラインになった場合、各サーバーが現在の状態で更新できることが重要です。
ZooKeeperのエフェメラル ノードを使用すると、すべてのサーバー ノードのプレゼンス情報を維持できます。
たぶん、Hadoop かそれに似たものがあなたのために働くでしょうか?
あなたが説明したことは、各マシンがデータセット全体のコピーをホストし、単一のノードに到達すると読み取りと書き込みが成功するように構成された Apache Cassandra クラスターを思い出させます (私はそれをしたことはありませんが、可能だと思います)。ノードは、WAN リンクがダウンしても機能を維持し、オンラインに戻るとすぐに保留中の更新を受信できる必要があります。それでも、魔法はありません。競合する更新が異なるサーバーで発行されたり、古いレプリカが新しいデータの生成に使用されたりすると、選択したアーキテクチャで一貫性の問題が発生します。
2 つ目の問題は、すべてのローカル書き込みに対して n-1 回のリモート書き込みが発生し、サーバーは誰が最新のレコードを持っているかを議論するために多くの時間と帯域幅を費やす可能性があることです。
いくつかの EC2 インスタンスを起動し、それらの接続を試して、すべてが期待どおりに機能するかどうかを確認することを強くお勧めします。これは「創造的な誤用」の領域にあるようであり、マイレージがまったくない場合でも、マイレージは大きく異なる可能性があります.