SpringBootとX DevApiを使用して真の非同期APIを構築
2339 ワード
reactorは世界を飲み込んでいるが、Java側だけは何も起こらなかったようだ.まだ多くのJavaerの非同期に対する理解は「httpリクエストを開始してサービスコールバックを待つ」か、「IOブロックの操作を別のスレッドに置く」にとどまっている.それだけでなく、Javaとその関連技術のroadmapで非同期であることも重要な話題ではない.もちろん、これも不思議ではありません.まず、非同期によるパフォーマンスの向上は実質的に限られていますが、モデルは特に複雑で、ビジネス規模が本当に向上しない限り、性価比はありません.また、ほとんどのCRUDのパフォーマンスのボトルネックは、データベース上では、一般的にひざまずいているのはデータベースサーバであり、アプリケーションサーバは最初から最後まで暇な状態です.最後にJavaが現在注目している高可用性などに比べて、性能はかえって最も解決した問題である--機械を加えるのではないでしょうか.
もちろん非同期はトレンドですが、非同期のコストがますます低くなると、Javaを行動しない江山にも座れない日があります.そこでJava 9はFlow,Spring 5はWebFluxを導入した.しかし、様々な繊程に比べて、原始人が21世紀に突入したような気がします.非同期の世界では、解決しなければならない3つの問題があると思います.統合非同期モデル これはJavaが今一番頭が痛いところかもしれません.C#はTask、JavascriptはPromise、CompletableFutureが出てくるのが遅すぎて、Guava、Netty、Apache HttpClientはすべて自分のFutureを持っていて、RxJava、Reactorを加えて、まったく一致したプログラミング体験ができません.箱を開けるのは難しい.一般的な非同期API 非同期はto be or not to beの問題であり、全非同期か、全同期か、漸進的なスキームは存在せず、IOに関連するすべてのAPIが非同期化されることが要求される.Javaの現在のこの方面の進度は本当に一言では言い尽くせないで、特にJdbcのこの1枚は遅々として物音がなくて、次のnosqlの山に比べてまだ前を歩いています.統合スレッドプール これは最も無視されやすい点かもしれません.非同期コードは依然としてスレッドで実行する必要があり、IO終了後のスレッドとIO呼び出しを開始するスレッドが1つのスレッドプールにない場合、スレッドのコンテキスト切替が依然として存在する可能性があり、最後の利点は、より少ないスレッド数で節約されたポイントスタック空間にすぎない可能性がある.統合されたスレッドプールは、コンポーネントに関連するすべてのスレッドスキームを統一する必要があることを意味します.C#のスキームはグローバルなスレッドプールを使用していますが、スレッドスケジューリングの詳細を隠しています.Javascriptは私にはスレッドが1つしかないと言っています.私はこの問題を心配していません.もちろん、本当の同時性はありません.Javaオンライン・スレッド・プールの利点は大きいが、スレッド・プールとファイバ・スレッドをどのように結びつけるかはまだ案がない.
Javaの非同期体験はあまりよくありませんが、JVMに緩和すると、Kotlinのcoroutineは目の前が明るくなり、最大のハイライトは各種の非同期案に適しており、繊維だけでなく、統一的な意味もあります.Springも公式のサポートを提供しており、もちろんKotlin自体には一定の学習コストがありますが、scalaよりはあまりよくありません.
データベースアクセスの面では、いくつかの非同期アクセスのプロジェクトも現れたが、死ぬのは難しい.Javaの同期生態があまりにも強く、動かないのも無理はない.驚きと意外なことにmysqlのX DevApiは非同期アクセスのインタフェースを提供しています.もちろんX DevApiが何なのかはまったく別の物語です.私たちが知っておくべきことは、これはmysqlの公式プロジェクトであり、oracleのお父さんが支えており、少なくとも品質とメンテナンスが保障されていることです.なお、X Protocolはprotobufsに依存する.
具体的なコードはGithubを参照して、簡単な呼び出しを繰り返して、各ステップのスレッドを印刷します
コールバックの実行スレッドは、現在のスレッドでも別のスレッドでもある可能性があり、suspendCoroutineのコメントもこのように記述されていることがわかります.行動から見ると,元のスレッドの忙しさが別のスレッドにスケジューリングされるはずであり,具体的には検討が必要である.
C#の体験まではまだまだですが、とうとうそんなことになりました.
もちろん非同期はトレンドですが、非同期のコストがますます低くなると、Javaを行動しない江山にも座れない日があります.そこでJava 9はFlow,Spring 5はWebFluxを導入した.しかし、様々な繊程に比べて、原始人が21世紀に突入したような気がします.非同期の世界では、解決しなければならない3つの問題があると思います.
Javaの非同期体験はあまりよくありませんが、JVMに緩和すると、Kotlinのcoroutineは目の前が明るくなり、最大のハイライトは各種の非同期案に適しており、繊維だけでなく、統一的な意味もあります.Springも公式のサポートを提供しており、もちろんKotlin自体には一定の学習コストがありますが、scalaよりはあまりよくありません.
データベースアクセスの面では、いくつかの非同期アクセスのプロジェクトも現れたが、死ぬのは難しい.Javaの同期生態があまりにも強く、動かないのも無理はない.驚きと意外なことにmysqlのX DevApiは非同期アクセスのインタフェースを提供しています.もちろんX DevApiが何なのかはまったく別の物語です.私たちが知っておくべきことは、これはmysqlの公式プロジェクトであり、oracleのお父さんが支えており、少なくとも品質とメンテナンスが保障されていることです.なお、X Protocolはprotobufsに依存する.
具体的なコードはGithubを参照して、簡単な呼び出しを繰り返して、各ステップのスレッドを印刷します
reactor-http-nio-2
Message listeners dispatching thread
Message listeners dispatching thread
Message listeners dispatching thread
reactor-http-nio-2
reactor-http-nio-2
reactor-http-nio-2
reactor-http-nio-2
reactor-http-nio-2コールバックの実行スレッドは、現在のスレッドでも別のスレッドでもある可能性があり、suspendCoroutineのコメントもこのように記述されていることがわかります.行動から見ると,元のスレッドの忙しさが別のスレッドにスケジューリングされるはずであり,具体的には検討が必要である.
C#の体験まではまだまだですが、とうとうそんなことになりました.