2

異なるノードで実行されている 2 つのプロセスがあり、それらがデータベースを共有している場合、1 つのノードがデータベースを介して他のプロセスに通知を送信できるパターンはありますか?
通常使用されるテーブルのポーリングのようなものですか、それともより良い方法がありますか?

4

5 に答える 5

3

ポーリング (これは、CPU サイクルだけでなく、この場合はデータベース リソースと帯域幅も消費することになります) の代わりに、これはどうですか? Oracle を使用している場合は、通知を受け取りたいテーブルに対して ON UPDATE トリガーを定義し、トリガーから Java ストアド プロシージャ (JSP) を呼び出すことができます。その後、JSP は任意の通知メカニズムを使用して、変更について他のコンポーネントに通知できます。これは非常に高速ではありませんが、まあ...

適切な方法は、データベースを更新するコンポーネントに並列通知を他のコンポーネントに送信させ、この RMI、JMS などで利用可能なテクノロジーを再び使用することです。

于 2012-12-12T16:24:17.773 に答える
2

データベースを使用する場合は、生成側でテーブルにエントリを挿入し、消費側でポーリングして新しいエントリを見つけることができます。これは、プロジェクトにとって最も簡単なオプションです。

JMI、RMI、ソケット、NoSql データベース、ファイルなど、多くの代替手段が考えられますが、より多くの情報がなければ、これらが優れているかどうかを判断することはできません。(多くの場合、最も単純なものが最適です)

于 2012-12-12T13:52:21.890 に答える
1

ポーリングは最適なソリューションではありません。多数のクライアントまたはユーザーがいる場合、データベースは世論調査員への回答に忙しくなります。

可能であれば、ユーザーが更新をブロックまたは待機することをお勧めします。ユーザーは通常、レスポンシブシステムを好みます。

決定する前に考慮すべき2つの主な基準は、同時ユーザーの最大数と、ユーザーが関心を示したイベントについてユーザーに通知する必要がある速さです。

于 2012-12-13T05:29:09.983 に答える
1

データベースがサポートしている場合、ポーリングよりも優れたソリューションは select() または inotify() のようなものです。たとえば、PostgreSQL は select() をサポートしているため、DB への入力を待機している間に非ビジー ループを実行できます。そうは言っても、Database-as-IPCはアンチパターンと見なされます。

于 2014-06-23T16:01:35.037 に答える
0

最も簡単な解決策は、別のプロセスをポーリングすることです。

ただし、別のプロセスがデータの変更をすぐに受け取りたい場合は、rpc、http リクエストなどの通知メカニズムの使用を検討する必要があります。

于 2012-12-12T14:06:34.507 に答える