うまくいけば、これはあまりにも主観的ではありません...
私は、非同期メッセージベースのプログラミングのアイデアに慣れていません。つまり、すべてが同時に実行され、受信したメッセージに応答してのみ動作する自己完結型の「ミニプログラム」のコレクションを作成することです。
このスタイルは必然的に多くの CPU サイクルを消費することを理解しています。
それ以外に、非同期メッセージ パッシング スタイルの賛成派と反対派は何ですか?
1 に答える
2
この種のプログラミングは、主に特定のクラスの問題を解決するのに役立ちます。主に、少量の作業を行うだけで多くの接続を処理する必要があるものです。電気通信交換機、証券取引所、インスタント メッセンジャー サーバーが自然に思い浮かびますが、賢い人はこのパターンをさまざまなことに使用できます。
このアプローチの大きな利点の 1 つは分散性であることが判明しました。これらすべてのプロセスを 1 台のマシンで実行するのではなく (通常、プロセッサよりも多くのプロセスを使用してもあまり効果がありません)、多くのマシンに簡単に均等に分散できます。 、ネットワーク経由で通信させます。これにより、通信交換機や電子証券取引所など、大量の小さな情報を迅速かつ効率的に処理する必要がある場合に、優れたスケーラビリティが実現します。
一方、このアプローチは、小さな断片に分割されないプログラムにはうまく機能せず、1 人のユーザーがアプリケーションを使用していてイベント ループが小さい場合にはまったく役に立ちません。これの良い例は、ほとんどすべてのデスクトップ アプリケーションです。99.9% の時間は最後のキー押下のイベント処理に費やされ、次のキー押下までに完了するため、多数のプロセスで実行されているワード プロセッサからは何も得られませんが、オーバーヘッドに費やされる時間は失われます。プロセスとメッセージング キューの管理。
それはさておき、非同期アプリケーションにはもう 1 つの大きな問題があります。共有データです。古典的なマルチスレッドの問題を見ることができます: アプリが ATM トランザクションを処理する銀行サーバーであるとしましょう。口座残高がロックされていないと、夫と妻が同時に給料を入金していると、お互いの操作が衝突して空売りになる可能性があります。非同期処理エージェントを使用すると、これらのケースが正しく処理されるようにするために多くの作業を行う必要があります。また、明白で簡単な解決策 (ロックなど) が、ボトルネックになったり、コード実行を線形化するという悪影響を与えることがあります。単一のアプリケーションよりも利益は得られませんでした。
于 2011-10-25T21:46:05.597 に答える