2

システムには、管理コンソールと稼働中のサーバーのクラスターが含まれています。アプリケーションの状態はデータベースに保存されます。管理コンソールから、ユーザーは新しいジョブを追加したり、実行中のジョブを監視したりできます。稼働中のサーバーは、dbからジョブをフェッチして処理します。

現在、一部の構成もデータベースに保存されています。構成は各稼働中のサーバーにもロードされ、構成は頻繁に変更されないため、ほとんどがキャッシュされます。

管理者は（管理コンソールから）構成を変更できます。変更はデータベースに保存されます。動作中のサーバーに変更をプッシュするための最良の方法は何でしょうか？

これまでの私の考え：

  1. 更新/削除/挿入時に構成テーブルにトリガーを追加し、一部のAuxテーブルのタイムスタンプを更新します。キャッシュにアクセスする前に動作している各サーバーは、このAuxテーブルに変更がないかチェックします。短所：まだdbにアクセスしています。

  2. 管理コンソールから、構成が変更され、次の呼び出しでdbから読み取る必要があるすべての稼働中のサーバーに要求を送信します。短所：管理者とサーバー間のhttp通信（これまで存在しなかった新しいレイヤー）と、それがどれほど信頼できるかについては疑問があります。

このテーマに関する経験はありますか？

4

1 に答える 1

0

最初のアプローチは、簡単なハックのように思えます。補助テーブルのタイムスタンプをチェックすると、キャッシュの目的がほとんど無効になります。

2番目のオプションが良いようです。これは、独自の構成キャッシュを更新するために、タスク キュー内の単純なタスクとして実装できます。

複数のサービスの構成を変更する主な問題は、それらの依存関係です。

親サービスがその子サービスと互換性のない構成で実行を開始すると、クラッシュまたは未定義の動作が発生する可能性があります。これを回避するには、同期を実装する必要があります。

1 つの方法は、親サービスにその構成を更新させてから、子サービスに構成更新コマンドを発行させることです。すべての子サービスが更新された後、親は処理を再開します。このアプローチの利点は、単純な管理コンソールが構成の変更について親サービスにのみ指示できることです。

もう 1 つの方法は、管理コンソールに依存サービスを処理させることです。親サービスにコマンドを送信して、実行を一時停止し、構成を更新し、再開コマンドを待ちます。その間、すべての子サービスを更新し、親に再開するように指示します。このようにして、サービスの依存関係がより柔軟になり、その構成が実装から切り離されます。これには、より高度な管理ツールが必要です。

于 2013-03-11T16:18:15.247 に答える