問題タブ [project-reactor]

リアクター ( https://github.com/reactor/reactor ) をシェーディングしようとしていますが、イベント バスの起動時に問題が発生しています。次のエラーが表示されます。このプロジェクトのシェーディングに関するアドバイスをいただければ幸いです

リアクタ EventBus とフェイルセーフの統合テストを実行しているときに NP が発生します

これは、クラス UUIDUtils がブートストラップ クラスローダーによってロードされているため、getClassLoader() の呼び出しが null を返しているためだと思いますか? Caused by: java.lang.NullPointerException at reactor.core.support.UUIDUtils.<clinit>(UUIDUtils.java:39)

IS_THREADLOCALRANDOM_AVAILABLE = null != UUIDUtils.class.getClassLoader().loadClass( "java.util.concurrent.ThreadLocalRandom" );

私はReactorを学んでいますが、特定の動作を実現する方法を知りたいと思っています。着信メッセージのストリームがあるとしましょう。各メッセージは特定のエンティティに関連付けられており、いくつかのデータが含まれています。

異なるエンティティに関連するメッセージを並行して処理できます。ただし、単一のエンティティに関連するメッセージは一度に 1 つずつ処理する必要があります。つまり、エンティティのメッセージ 2 の処理は、"abc"エンティティのメッセージ 1 の処理が終了するまで開始できません"abc"。メッセージの処理が進行している間、そのエンティティの後続のメッセージをバッファリングする必要があります。他の実体へのメッセージは妨げられずに進むことができます。次のようなコードを実行しているエンティティごとにスレッドがあると考えることができます。

ブロックせずにReactでこれを達成するにはどうすればよいですか? 合計メッセージ レートは高くなる可能性がありますが、エンティティごとのメッセージ レートは非常に低くなります。エンティティのセットは非常に大きくなる可能性があり、必ずしも事前にわかっているとは限りません。

おそらくこんな感じだと思いますが、わかりません。

Reactor-EventBus イベントが発生し、ハンドラーが登録されていない場合、特にメモリ自体とそのデータ ペイロードの使用はどうなりますか?

処分されるのでしょうか？それとも、これらの Event オブジェクトはリングバッファに収集されますか?

処分されると思いますが、その点はご了承願いたいです。

私はETLプロジェクトに取り組んでいます。私は長い間春の統合を使用してきました。現在、データ ソースはファイルまたはクロニクルですが、ライブ ストリームに変更される可能性があり、量が増える可能性があります。将来的にはビッグデータ ソリューション (hadoop、spark など) に移行する可能性があります。

これに基づいて、スプリング統合とリアクティブ ストリームを比較する必要がありますか? なぜ誰かが一方を他方よりも優先して使用するのでしょうか (または、そもそも 2 つを比較しようとしている私が間違っているのでしょうか)。一緒に使用できると思われるシナリオ (ある場合) はありますか?

でイベントをキャプチャした後、別のスレッドを（Reactorまたはを使用して）生成したい。私は直面しています、正確に何が起こっていますか? いろいろ調べたところ、ディスパッチャーがディスパッチされたオブジェクトのコピーまたは保存を許可していないことがわかりました。どういう意味ですか？助けてください。EventBus@HandleAfterCreateSpringBootApplicationIllegalStateException

例外メッセージ

私の環境

• org.springframework.boot:spring-boot-starter-data-rest
• spring-boot-starter-data-jpa:1.2.6
• com.h2database:h2:1.4.189
• org.projectreactor:reactor-spring:1.0.0

今日の私の質問は、マイクロサービスを構築する際の組み合わせ操作についてです。

架空のシナリオを使用してみましょう: ダッシュボードを構築したいです。ダッシュボードは、多数のユーザーとその情報 (履歴、レビュー、購入、最後に検索された製品) で構成されています。

spring-cloud と spring-reactor を読んで、ユーザー サービス、レビュー サービス、検索エンジン サービスなど、複数のマイクロサービスを呼び出すノンブロッキング ソリューションを希望します。

私の最初の推測は、次のようなことをすることでした

• ユーザーをロードし、
• それぞれがそのレビューをロードしてから
• その履歴をロードしてから
• すべてのデータを組み合わせる

のような疑似コードでloadUsers().flatmap(u -> loadReviews(u))....reduce()。ご覧のとおり、ここでは本当におおよそです。

1 人のユーザーをロードする場合、さらに 4 回の http 呼び出しが必要であると見積もることができます。100 人のユーザーの場合、400 の追加の呼び出しなど。Big-O は直線的ではないようです。

マイクロサービスが XYZ マイクロサービスからのデータ読み込みも委任する最悪のケースでは、1 ユーザーの場合 -> 1 件のレビュー コールを含む N 件のコール -> 1 件の XYZ コールとなります。申し訳ありませんが、Big-O (二次 ?) を計算していません。

それを避けるために、おそらくすべてのユーザーをロードし、ID を抽出し、ID のバッチを使用して EARCH マイクロサービスを呼び出すことができます。各マイクロサービスは一度にすべてのデータを読み込むことができ (ID でマップされたレビューのリスト)、元の呼び出しはすべてのこれらのリストをマージします。（zip機能の一種）

概要: Observables の構成に関するこの質問を読みました。私の質問は、「チェーンの最初に一意のユーザーがなく、数百人のユーザーがいる場合、同じ戦略を使用しますか?」と要約できます。（パフォーマンスは問題になる可能性がありますか？）