データベースレプリケーションとカスタムのどちらを使用するかを決定する方法RESTアプリケーションとメッセージブローカー（pub / sub）
現在設計中の分散ソリューションがあります。一部のアプリケーションが他の誰かからのデータを必要とする、またはその逆の統合がいくつかあります。 RESTインターフェイスを記述し、アプリがそれらの間でデータを共有できるようにCRUD機能を提供することで解決できます。または、nanomsgやzeroMQなどを使用してメッセージを送受信することもできます。
また、プライマリとセカンダリのDBサーバー間でマスターツーマスターレプリケーションを実行して、一方がダウンしても他方が起動できるようにするH/A要件もあります。
ここに質問があります。チームの何人かは、マスターからマスターへのレプリケーションのようなデータを共有する1つの方法を選択し、データを「共有」するために全体で使用する必要があると感じています。それができるのは事実ですが、次のような特定の基準に応じて、各ケースを個別に分析して処理する必要があると思います。
- 問題のデータベースは同一ですか？そうである場合は、高可用性シナリオのように、マスターツーマスターが適切です。
- 異種システムの場合、どのくらいの量のデータが行き来していますか？データ量が多い場合は、メッセージバスの方が良いでしょう。 「変更があります...変更IDがあります。変更してください」という通知を送信するだけです。
- データはどのくらいの頻度で変更されますか？これは問題ですか？ REST apiとメッセージバスの両方が多くのトランザクションを処理できるようになると思います。
他に何を検討すればよいかわかりません。メッセージバスソリューションの作成は、各データベースへのREST apiよりもはるかに多くの作業になると思われます。しかし、私は間違っている可能性があります。他に何を考慮する必要がありますか？
ありがとう。
データベースへの共有アクセスを使用するだけで、データを共有（読み取りおよび書き込み）allしてトランザクションを使用する必要がある場合。高可用性が必要な場合は、 マスター/スレーブレプリケーションの使用を検討してください 。マスターマスターと盲目的に行くだけではなく、慎重に考えてください 不利な点 ：
- ほとんどのマルチマスターレプリケーションシステムは、緩やかに整合しているだけです。つまり、遅延および非同期であり、ACIDプロパティに違反しています。
- 熱心な複製システムは複雑で、通信の待ち時間が長くなります。
- 関与するノードの数が増加し、レイテンシが増加するにつれて、競合の解決などの問題は扱いにくくなる可能性があります。
REST短所：
- 実際に実装、テスト、サポートする必要があります。
- 最悪の考えであるAPIレイヤーでトランザクションを再発明しない限り、複数のリソースでのトランザクションはありません。
メッセージキューcons：
- データの共有には適していません。 MQは非同期のプロセス間通信に適しています。コマンドの呼び出し、イベントの起動などです。
- 繰り返しになりますが、データをキューに入れるだけでは魔法のように共有されないため、メッセージハンドラーを実装、テスト、およびサポートする必要があります。
ただし、共有するデータの一部部分だけが必要で、マルチリソーストランザクションが不要な場合は、REST（または多分JSON-RPC）の方が良いソリューションかもしれません。
それでも、MQは、私が言ったように別の一連の問題を解決するので、悪い解決策になるでしょう。
あなたの質問への答えは、実際に何が必要かによって異なります。
- すべてのデータをそのまま共有し、トランザクションで使用できるようにする-共有DB
- 細かく均一な方法で一部のデータを共有する（CRUD）-REST
- データのさまざまな部分や重要なロジックを伴う操作-JSON-RPC
- 非同期のプロセス間通信-メッセージキュー