問題タブ [quasar]

私は最近、「軽量」/Go のような「ユーザー モード」スレッドを JVM に提供するQuasarについて読みました (Akka のような Erlang にインスパイアされた Actor システムもありますが、それは主な問題ではありません)。

例えば：

上記のコードがJVM /カーネルスレッドを生成しないことを理解する限り、すべてはユーザーモードスレッドで行われ（または彼らが主張する）、安価であるはずです（私が正しく理解していればGoコルーチンのように）

私の質問はこれです-私が理解している限り、AkkaではすべてがまだJVMスレッドに基づいており、ほとんどの場合ネイティブOSカーネルスレッド（POSIXシステムのpthreadsなど）にマップされています。ユーザー モード スレッドがない / コルーチンのように動作する / Akka の軽量スレッド、正しく理解できましたか?

もしそうなら、それが設計上の選択かどうか知っていますか? それとも将来、Akka に go のような軽量スレッドを実装する計画はありますか?

私の理解では、100 万のアクターがあり、そのほとんどがブロックしている場合、Akka ははるかに少ない物理スレッドで処理できますが、それらのほとんどが非ブロックであり、システムからの応答性が必要な場合 (例: 100 万の小規模なサービス)いくつかのデータをストリーミングするための要求) の場合、ユーザー モードのスレッド化の実装の利点を確認できます。多くのクライアントがありますが、応答性は依然として重要です)

私の理解は多かれ少なかれ正しいですか？私が間違っている場合は修正してください。

_{*ユーザーモード スレッドと go/co-routine および軽量スレッドを完全に混同している可能性があります。上記の質問は、それらがすべて同じものであるという私の不十分な理解に依存しています。}

SBT プロジェクトでQuasarを使用したいと考えています。Scala はまだサポートされていないため、残された唯一の実行可能なオプションは、Quasar を使用するいくつかの Java クラスを SBT でコンパイルすることです。

入れてみた

と

私が読んだように、たとえばJRebelを使用するには、これらのステートメントの両方をbuild.sbtに挿入する必要があります

しかし、Quasarish クラス ( QuasarExample )を使用すると、次のように動作しないようです。

インストルメンテーションが成功した後、エラーなしで実行されると予想されるコードの一部:

スターターについては、このリポジトリも参照してください。

同じスレッドでN 個のタスクを実行する必要があるとします。タスクでは、外部ストレージからの値が必要になる場合があります。どのタスクがいつそのような値を必要とするかは事前にわかりません。Mクエリで同じM値を外部ストレージにフェッチするよりも、一度にM値をフェッチする方がはるかに高速です。

タスク自体からの連携は期待できないことに注意してください。タスクは単なる java.lang.Runnable オブジェクトと見なすことができます。

さて、理想的な手順は、私が見ているように、次のようになります

1. すべてのタスクをループで実行します。タスクが外部値を要求する場合は、これを覚えておいて、タスクを中断 して次のタスクに切り替えてください。
2. 前のステップで要求された値を一度にフェッチします。
3. 完了したすべてのタスクを削除します (中断されたタスクは完了したと見なされません)。
4. まだタスクが残っている場合は、手順 1 に進みますが、タスクを実行するのではなく、中断された状態から実行を続けます。

私が見る限り、何かを「一時停止」および「再開」する唯一の方法は、関連するフレームを JVM スタックから削除し、それらをどこかに保存し、後でそれらをスタックに戻して JVM を続行させることです。

これを行うための標準的な (JVM バイトコードよりも低いレベルでのハッキングを含まない) 方法はありますか?

または、これを達成するための別の方法を提案できますか ( Nスレッドを開始するか、タスクを何らかの方法で連携させる以外に)。

アプリで Quasar ファイバーを使用しようとしていますが、このライブラリが Android JVM に適していないかどうか疑問に思っています。

私は私の中に持っていますbuild.gradle：

ビルドを実行すると、gradle コンソールに次の出力が表示されます。

私は立ち往生しています、誰が私が何をすべきか知っていますか? これでも機能しますか？

私が知っているように、最も一般的な JVM 同時実行 API の 1 つである先物 (少なくとも scala で実装されているもの) は、アイドル状態で待機する可能性がある場合に、ユーザー コードに依存してスレッドを放棄します。scala では、これは一般に「ブロッキングの回避」と呼ばれ、開発者は意味のあるあらゆる場所に実装する必要があります。あまり効率的ではありません。

オペレーティング システム プロセス スケジューラによって実装されているように、スレッドがアイドル状態のときに、JVM がスレッドのコンテキストを新しいタスクに切り替えるのを防ぐ、JVM に完全に固有の何かがありますか?

私の知る限り、Akkaでは、すべてのアクターがスレッドのプールでスケジュールされています。ブロッキング IO を同時に実行するアクターが多すぎると、各ブロッキング呼び出しが 1 つのスレッドをブロックし、スレッドの停止につながります。

現在、私は JVM での興味深いファイバーの実装 ( Quasar ) を検討しています。これは、多くのユーザー スレッド (ファイバー) を許可し、スレッド プールを使用してそれらをスケジュールします。ただし、多くのファイバーが従来のブロッキング API を呼び出すことに利点があるかどうかは疑問です。

ブロッキング API は依然としてシステム スレッドをブロックし、Quasar はそれを魔法のようにファイバーのみをブロックするように変えることができなかったので、それは役に立たないと思います。あくまで私の推測ですので、間違っていたらご指摘ください。

内部ノード間通信に現在 HTTP/REST を使用しているマイクロサービス アーキテクチャの最適化を検討しています。

1 つのオプションは、バックプレッシャ機能をサービスに実装することです (たとえば、Quasar のようなものをスタックに統合することによって)。これは間違いなく物事を改善するでしょう。しかし、いくつかの課題があります。1 つは、非同期クライアント スレッドが一時的 (メモリ内) であり、クライアントに障害 (クラッシュ) が発生すると、これらの再試行スレッドが失われることです。2 つ目は、理論的には、ターゲット サーバーがしばらくダウンしている場合、クエーサー ファイバーであってもスレッドが最終的に制限されるため、クライアントは再試行を試みて最終的に OOM に到達する可能性があります。

少し偏執的であることはわかっていますが、キューベースの代替手段が非常に大規模な場合により有利になるかどうか疑問に思っています。

ただし、a) キューが中央で管理され、クライアント JVM から切り離されていること、b) キューが永続的であるため、クライアントやターゲット サーバーがダウンした場合、処理中のメッセージがないことを除きます。失われます。

もちろん、キューの欠点は、ホップが多くなり、システムの速度が低下することです。しかし、Quasar の ROI がピークに達し、一元化された耐久性のあるキューがスケーリングと HA にとってより重要になるスイート スポットがおそらくあると思います。

私の質問は：

このトレードオフは議論されましたか? サービス内通信に集中型の外部キュー/ルーター アプローチを使用することに関する論文はありますか。

TL;DR; この質問はおそらく次のように表現できることに気付きました。

「マイクロサービス アーキテクチャ内で直接 HTTP を使用するのではなく、メッセージ バス ベースのサービス内通信を使用するのが適切なのはいつですか。」