2

ここで読んだようにhttp://mechanitis.blogspot.fr/2011/06/dissecting-disruptor-how-do-i-read-from.html

「個々のアイテムごとに、消費者は単に「この数を超えたら教えてください」と言い、その見返りに、あと何個のエントリを取得できるかを通知されます。」

これは、Erik Meijer http://www.youtube.com/watch?v=8Mttjyf-8P4によって公開されている Rx フレームワークの概念に関連していません か?

はいの場合、Rx フレームワークは同様のソフトウェアを実装するのに役立ちますか?

4

2 に答える 2

4

良い質問です。現在のプロジェクトの 1 つについて、私自身、これについて疑問に思っていました。

ただし、決定的な答えを出す資格はあまりないと思います。

それらは、さまざまなかゆみを掻くように設計されています。

Disruptor は、可能な限り金属に近いパフォーマンスを第一に明確に設計されています。それはそれがすること以外に空想的なことは何もしません。

Rx はより高いレベルであり、「Linq to events」であり、通常のフレームワーク イベントではできなかった「イベント」を使用して素晴らしいことを行うことができます (標準イベントをフィルター処理して、それをイベントとして伝播し続けることはできません)。 ）。

意味上の違い

Disruptor.Netの創始者がここで指摘したように：

インターフェイスは一致しますが、RX の背後にあるセマンティックは一致しないと思います。

  • 例外 (OnError) はストリームを終了しますが、これはディスラプターには当てはまりません
  • ディスラプターがホットな間はサブスクライブできません: オブザーバーは、ディスラプターを「開始」する前にセットアップする必要があります。これは、たとえば、エラーの場合に再サブスクライブする再試行などのオペレーターではうまく機能しません。
  • 多くのオペレーターはディスラプターで意味をなさないか、単に機能しません

そうは言っても、彼は（少なくとも一度は）Disruptor.Net、TPL Dataflow、および Rx の統合について考えていました。

これは、誰かが同じ質問をする別のページです。ページは次のように締めくくられています。

私の意見では、Disruptor は実際には TPL DataFlow に似ています。

于 2012-05-04T12:22:39.360 に答える
1

Rx フレームワークを知らなくても、あなたは正しいかもしれません。ただし、Disruptor.Net は Java バージョンのポートになるように設計されているため、可能な限り類似しています。オリジナルが Rx を使用していないことを考えると、別のライブラリを使用すると、多くの再作業が追加され、パフォーマンスの問題が発生する可能性があります。

于 2012-05-01T10:00:57.223 に答える