次の方法で共有

Orleans を使用したストリーミング

Orleans ストリーミングは、一連のイベントを構造化された方法で操作するリアクティブ アプリケーションを開発者が記述できるようにする、 Orleans フレームワークの機能です。 Orleans ストリーミングには、ストリームをよりシンプルで堅牢なものにすることを考え、操作するための一連の抽象化と API が用意されています。 ストリームは、常に存在し、失敗しない論理エンティティです。 ストリームは、その StreamIdによって識別されます。 ストリームを使用すると、時間と空間の両方で、データの生成を処理から切り離します。 ストリームは、グレインと Orleans クライアント間で均一に機能し、Event Hubs、ServiceBus、Azure Queues、Apache Kafka など、幅広い既存のキュー テクノロジと互換性があり、移植可能です。 Orleans ストリーミングでは、動的ストリーム バインド、透過的なストリーム消費ライフサイクル管理、拡張可能なストリーム プロバイダーもサポートされています。

Orleans v.1.0.0 では、プログラミング モデルにストリーミング拡張機能のサポートが追加されました。 ストリーミング拡張機能には、ストリームの考え方と操作をよりシンプルで堅牢なものにする一連の抽象化と API が用意されています。 ストリーミング拡張機能を使用すると、開発者は一連のイベントを構造化された方法で操作するリアクティブ アプリケーションを記述できます。 ストリーム プロバイダーの拡張性モデルにより、プログラミング モデルは 、Event Hubs、 ServiceBus、 Azure Queues、 Apache Kafka など、さまざまな既存のキュー テクノロジと互換性があり、移植可能になります。 このようなキューを操作するために、特別なコードを記述したり、専用のプロセスを実行したりする必要はありません。

なぜ私は気にする必要がありますか?

ストリーム処理に関する知識が既にあり、.NET の Event Hubs、Kafka、Azure Stream Analytics、Apache Storm、Apache Spark Streaming、Reactive Extensions (Rx) などのテクノロジに精通している場合は、気にする必要がある理由を尋ねる場合があります。 別のストリーム処理システムが必要な理由と、アクターとストリームの関係"なぜ Orleans ストリーム?" は、その質問に答える目的です。

プログラミング モデル

Orleans ストリーム プログラミング モデルの背後には、いくつかの原則があります。

  1. Orleans ストリームは 仮想です。 つまり、ストリームは常に存在します。 明示的に作成または破棄されることはなく、失敗することもありません。
  2. ストリームは、GUID と文字列で構成される論理名であるストリーム ID によって識別されます。
  3. Orleans ストリームを使用すると 、時間と空間の両方で、データの生成を処理から切り離します。 つまり、ストリーム プロデューサーとストリーム コンシューマーは、異なるサーバーまたは異なるタイム ゾーンにある可能性があり、障害に耐えられます。
  4. Orleans ストリームは 軽量で動的です。 Orleans ストリーミング ランタイムは、高いレートで送受信される多数のストリームを処理するように設計されています。
  5. Orleans ストリーム バインドは動的です。 Orleans ストリーミング ランタイムは、グレインがストリームに接続してストリームから切断するケースを高いレートで処理するように設計されています。
  6. Orleans ストリーミング ランタイムは 、ストリーム消費のライフサイクルを透過的に管理します。 アプリケーションはストリームをサブスクライブした後、障害が発生した場合でもストリームのイベントを受信します。
  7. Orleans ストリームは 、グレインと Orleans クライアント間で均一に機能します。

クイックスタートサンプル

クイック スタート サンプルは、アプリケーションでストリームを使用する全体的なワークフローの簡単な概要です。 読んだ後は、 Streams プログラミング API を 読んで、概念をより深く理解する必要があります。

ストリーム配信提供者

ストリームは、さまざまな図形や形式の物理チャネルを介して取得でき、異なるセマンティクスを持つことができます。 Orleans ストリーミングは、システムの拡張ポイントである Stream Providers の概念を通じて、この多様性をサポートするように設計されています。

Orleans には、いくつかのストリーム プロバイダー実装が用意されています。

Orleans 現在、いくつかのプロバイダー実装が含まれています。

  • 簡易メッセージ (SMS)は、直接的なグレイン呼び出しを使用し、バックアップストレージシステムを使用しません。
  • Azure キューは、Azure Storage キューを使用してメッセージを格納します
  • Azure EventHubs(Azure EventHubs を使用)

詳細については、「 ストリーム プロバイダー」を参照してください。

ストリーム セマンティクス

ストリームサブスクリプションの意味論:

Orleans ストリームは、Stream サブスクリプション操作の シーケンシャル整合性 を保証します。 具体的には、コンシューマーがストリームをサブスクライブするときに、サブスクリプション操作を表す Task が正常に解決されると、コンシューマーには、サブスクライブ後に生成されたすべてのイベントが表示されます。 さらに、巻き戻し可能なストリームを使用すると、 StreamSequenceTokenを使用して過去の任意の時点からサブスクライブできます。 詳細については、「 Orleans ストリーム プロバイダー」を参照してください。

個々のストリーム イベント配信の保証:

個々のイベント配信の保証は、個々のストリーム プロバイダーによって異なります。 一部のシステムでは、ベストエフォートで多くても1回の配信のみを提供するものがあります（バージョン7.0より前のOrleansではSimple Message Streams（SMS）がこれに該当し、それ以降はブロードキャストチャネルと呼ばれます）。これに対して、Azureキューストリームのように、少なくとも1回の配信を保証するものもあります。 正確に 1 回の配信を保証するストリーミング プロバイダーを構築することも可能です。

イベント配信順序:

イベントの順序は、特定のストリーム プロバイダーにも依存します。 SMS ストリームでは、プロデューサーは、コンシューマーが表示するイベントの順序を、コンシューマーが公開する方法を制御することによって明示的に制御します。 基になる Azure キューでは障害発生時の順序が保証されないため、Azure キュー ストリームでは FIFO の順序は保証されません。 アプリケーションでは、 StreamSequenceTokenを使用してストリーム配信の順序を制御することもできます。

ストリームの実装

Orleans ストリーム実装では、内部実装の概要を説明します。

コード サンプル

グレイン内でストリーミング API を使用する方法の他の例については 、SampleStreamingGrain.csを参照してください。

こちらも参照ください