リアクティブプログラミングの利点/欠点
私は、ReactorとRxJavaを使用して、Reactive Styleコーディングの勉強と試行を続けています。リアクティブコーディングは、シングルスレッド実行と比較してCPUの使用率が向上することを理解しています。
Webベースのアプリケーションで、リアクティブプログラミングと命令型プログラミングの間に具体的な比較はありますか？
非リアクティブプログラミングではなくリアクティブプログラミングを使用することで、パフォーマンスの向上とスループットはどの程度達成されますか？
また、リアクティブプログラミングの長所と短所は何ですか？
統計的なベンチマークはありますか？
リアクティブプログラミングとは、ネットワーク呼び出しなどのすべてのIOバインドタスクを非同期に実行することを意味します。たとえば、アプリケーションが外部REST APIまたはデータベースを使用すると、その呼び出しを非同期で実行できます。そうすると、現在のスレッドはブロックされません。1つまたは少数のスレッドを生成するだけで、多くの要求に対応できます。詳細については、マルチパートのブログ投稿 パート1 、 パート2 、および パート を参照してください。
それ以外は、コールバックを使用して同じことを行うことができます。コールバックを使用して非同期呼び出しを行うことができます。しかし、もしそうすると、コールバック地獄になってしまうかもしれません。あるコールバックを別のコールバックに入れると、維持するのが非常に難しい非常に複雑なコードになります。一方、RxJavaは、はるかにシンプルで構成可能で読みやすい非同期コードを作成するのに役立ちます。また、RxJavaはMap、Zipなどの強力な演算子を多数提供します。これにより、互いに依存しないさまざまなタスクの並列実行によりパフォーマンスが向上し、コードがはるかに簡単になります。
RxJavaは、演算子セットを備えた別のObserver実装ではなく、優れたエラー処理と再試行メカニズムを提供します。これは本当に便利です。
しかし、統計的に称賛するために、命令型プログラミングアプローチでRxJavaのベンチマークを行ったことはありません。しかし、RxJavaはブロッキングメカニズムよりも優れたパフォーマンスを発揮するはずです。
更新
時間をかけてより多くの経験を集めたので、答えにもっとポイントを加えることを考えました。
記事 に基づいて、ReactiveXは、監視可能なシーケンスを使用して非同期およびイベントベースのプログラムを作成するためのライブラリです。そもそもこの入門記事を読むことをお勧めします。
これらは、リアクティブシステムのいくつかのプロパティです。イベントドリブン、スケーラブル、レジリエント、レスポンシブ
RxJavaに関しては、プログラマーに2つの主要な機能を提供します。まず、Zip、concat、mapなどの豊富な演算子セットを使用して、ニースの構成可能なAPIを提供します。これにより、よりシンプルで読みやすいコードが生成されます。コードに関しては、読みやすさとシンプルさが最も重要なプロパティです。第二に、優れた抽象化を提供し、並行性を宣言的にすることができます。
一般的な誤解は、Rxはデフォルトでマルチスレッドであるということです。正直に言うと、Rxはデフォルトでシングルスレッドです。非同期的に処理する場合は、関連するスケジューラを渡すことで、subscribeOnおよびobserveOn演算子を使用して明示的に通知する必要があります。 RxJavaはスレッドプールを提供して、非同期タスクを実行します。 IO、計算など、多くのスケジューラがあります。 IO名前が示すようにスケジューラは、IOネットワーク呼び出しなどの集中タスクに最適です。逆に、計算スケジューラは、CPU集中の計算タスクに適しています。また、RxJavaを使用して独自のExecutorサービスを接続することもできます組み込みのスケジューラは、主に独自のExecutorサービスを維持するのを取り除き、コードをよりシンプルにします。
最後にsubscribeOnとobserveOnの単語
Rxの世界では、通常、並行性モデルを制御するために次の2つのことがあります。
- サブスクリプションの呼び出し
- 通知の監視
SubscribeOn：Observableが動作するスケジューラを指定します。
ObserveOn：オブザーバーがこのObservableを監視するスケジューラーを指定します
短所
- ほとんどの場合、データのストリームを保存するためにより多くのメモリを消費します（時間の経過に基づいたストリームであるため）。
- 開始時に学ぶのは型破りであると感じるかもしれません（すべてがストリームである必要があります）。
- ほとんどの複雑さは、新しいサービスの宣言時に対処する必要があります。
学ぶべき優れたシンプルなリソースの不足。
機能的リアクティブプログラミングと同等であると混同されることがよくあります。
ブロッキング機能がないことに関して既に回答していることとは別に、リアクティブプログラミングを使用するもう1つの優れた機能は、バックプレッシャーの重要な使用です。通常、パブリッシャーがコンシューマーが処理できるよりも多くの情報を発行する状況で使用されます。
したがって、このメカニズムを使用すると、両方の間のトラフィックの流れを制御し、メモリ不足の問題を回避できます。
あなたはここでリアクティブプログラミングのいくつかの実践例を見ることができます https://github.com/politrons/reactive
バックプレッシャーについてはこちら https://github.com/politrons/Akka/blob/master/src/main/scala/stream/BackPressure.scala
ところで、リアクティブプログラミングの唯一の欠点は、プログラミングのパラダイムを変えているため、学習の曲線です。しかし、今日では、すべての重要な企業がリアクティブマニフェストを尊重し、それに従っています http://www.reactivemanifesto.org/
リアクティブプログラミングは、インテリジェントなルーティングとイベントの消費を伴うマイクロアーキテクチャのスタイルです。
リアクティブとは、少ないリソースでより多くのことを実行できることです。具体的には、少ないスレッドで高い負荷を処理できます。
リアクティブタイプは、リクエストやデータをより速く処理できるようにすることを目的としておらず、より多くのリクエストを同時に処理し、リモートサーバーからのデータのリクエストなど、レイテンシーのあるオペレーションをより効率的に処理する能力に長所があります。
リソースを消費することなく、時間と遅延をネイティブに処理することで、より良いサービス品質と予測可能な容量計画を提供できます。
から
https://blog.redelastic.com/what-is-reactive-programming-bc9fa7f4a7fchttps://spring.io/blog/2016/06/07/notes-on-reactive-programming-part-i-the-reactive-landscapehttps://spring.io/blog/2016/07/28/reactive-programming-with-spring-5 -0-m1
長所
- より簡潔なコード、より簡潔に
- 読みやすくなりました（一度理解したら）
- より簡単にスケーリング（任意の操作をパイプ）
- エラー処理の改善
- イベント駆動型のインスピレーション->ストリーム（Kafka、RabbitMQなど）とうまく連携
- バックプレッシャー（クライアントはフローを制御できます）
短所
- 場合によっては、より多くのメモリを消費する可能性があります
- やや急な学習曲線
リアクティブプログラミングは、命令型プログラミングの一種です。リアクティブプログラミングは、一種の並列プログラミングです。並列ブランチを作成する場合にのみ、シングルスレッド実行よりもパフォーマンスを向上させることができます。それらは複数のスレッドによって実行されるか、リアクティブな構造（実際には非同期プロシージャ）によって実行されるかは問題ではありません。
マルチスレッドプログラミングに対するリアクティブプログラミングの唯一の利点は、メモリ消費が少ないことです（各スレッドに0.5〜1メガバイトが必要です）。欠点は、プログラミングが簡単ではないことです。