Redis スレッド モデルのグラフィカル分析

この記事では、Redis に関する関連知識を提供します。主にスレッド モデルに関する関連問題を紹介します。Redis は単一のスレッドです。一緒に見てみましょう。皆さんのお役に立てれば幸いです。

推奨学習: Redis ビデオ チュートリアル

Redis は単一スレッドであるため、注意が必要ですに。

まず、クライアントを用意します。このクライアントは、実際に redis クライアントのようなツールを使用して、私たちの前に redis サーバーに接続しました。
後で Java に統合すると、対応するクライアントは実際には Java で提供されます。

次に、実際には Redis の 1 つである Redis サーバーを用意します。サービス全体が開始された後、プロセスが存在します。
私たちのリリースでは、実際には内部的に 2 つの機能があります。

まず、前のレッスンですでに紹介した、ノンブロッキング モデルであるマルチプレクサーがあります。
そして、実際には、いくつかのイベントを割り当てるために特別に使用されるファイル イベント アロケーターがあります。

この下では 3 つの異なるプロセッサに分かれています。それぞれを見てみましょう。

最初に接続応答プロセッサがあり、最後にコマンド要求プロセッサ、そしてコマンド応答プロセッサがあります。

どうやって理解すればいいでしょうか？まず、接続応答ハンドラーを見てみましょう。

応答プロセッサに接続するときの主な機能の 1 つは、クライアントとのリンクを維持することです。
Redis サーバーの 1 つが起動すると、実際には接続レスポンダーに読み取りイベントがバンドルされます。
その完全名は実際には AE_readable と呼ばれます。これは兆候と考えることができ、そのようなイベントが発生し、このイベントは接続応答プロセッサーにバンドルされます。

最後に、クライアントの 1 つとサーバーが接続を確立しようとしているとき、これは実際には最初にコマンド ライン ツールに Redis クライアントを入力したことを意味しており、これは最初に必ず必要です。当社のサーバーとの接続を確立します。接続を確立するとき、実際には読み取りフラグが送信されますが、これは実際には読み取り時間であり、この時点で、redis サーバーには実際にはサーバーソケットがあります。

サーバー ソケットは実際にはクライアント ソケットの 1 つに対応しており、ネットワーク プログラミングのコンテンツの一部であり、それらの間の通信がソケットです。 read などのイベントに遭遇すると、それをマルチプレクサーに渡して処理します。
彼に処理を任せると、彼は実はノンブロッキングで、受け取ったら我々と同じように矢に入れてくれます。

この矢印については、実際にはパイプラインと呼ぶこともできますし、キューと呼ぶこともできます。ここにスローされます。スローされた後、このワールドは実際にファイル イベント ディスパッチャーに到達します。このアロケータが読み取りイベントであることを認識すると、接続応答プロセッサと一致します。つまり、処理のためにアロケータを渡します。
一致する読みです。
現時点では、クライアントとサーバーが接続を確立していることが実際に示されています。接続が確立された後、読み取りフラグが設定されている場合、このイベントは実際にコマンド要求プロセッサーに渡されます。このコマンドがプロセッサーを要求する場合、それは特に要求を処理するもの、つまりリクエストであると考えることができます。そうすると、コマンド応答プロセッサー、応答、つまり応答として理解できます。

その後、クライアントに行く必要があるかもしれません。たとえば、値を設定する必要がありますよね。たとえば、set name *** のように値を設定すると、それは実際にはコマンドになります。
このコマンドのワールド タイプの 1 つは、実際には読み取りです。次に、サーバー ソケットを介してマルチプレクサにスローされ、取得後キューに入れられ、ファイル イベント ディスパッチャーに渡されます。

これを受け取ったファイルイベントディスパッチャは判定を行い、一致したイベントは読み込みイベントであると判断します。現時点で読み取りイベントの場合、コマンド要求プロセッサーはコマンドを処理するように求められます。彼はそれを認識し、現在のものが***というセット名であることを認識し、処理を実行します。彼は、ユーザーが設定したコンテンツを保存し、このキーの値をメモリに保存したいと考えています。これは実際にはリクエストであるコマンドリクエストの処理です。

処理されると、書き込まれた識別子である白が割り当てられます。ここにこのロゴを書いておけば、実際にレスポンスとして使えます。リクエストの 1 つが実際に処理された後、コマンドの入力が完了すると、「OK」が表示される可能性があるからです。これが問題ない場合、実際には、コマンド応答プロセッサの 1 つによって書き戻されたコンテンツと同等になります。そこで彼は書き込みによって書かれたマークを使用します。このようにして、書き込んだタグの 1 つが実際にコマンド応答プロセッサーにバンドルされます。 write については、正式名は AE_writable というイベント タイプです。

さて、クライアントでは実際にライトバックを行う必要があります。それは問題ありませんが、リストをクエリしていてリスト内のすべてのコンテンツを表示したい場合は、実際にはライトバックが発生します。コンソールの下部に書き込みなどのイベントタイプのコンテンツを表示したいと考えています。次に、それはマルチプレクサに渡され、キューの 1 つにスローされ、ファイル イベント ディスパッチャーの 1 つに割り当てられます。今回は弊社のWebイベントとマッチングさせていただきます。 Web イベントが一致しました。

その後、コマンド応答プロセッサがライトバックを実行します。 OKや取得したリストの番号、リストの内容などを記載します。表示する必要があるコンテンツがある限り、それは応答として使用されます。つまり、応答のコンテンツはクライアントの 1 つに書き戻され、クライアント上に表示されます。現在のモデル全体に​​は、実際には 2 つの異なるイベントがあり、1 つは読み取り可能と呼ばれ、もう 1 つは書き込み可能と呼ばれます。

もちろん、現在設定しているのは 1 つのクライアントだけですが、複数のクライアントがある場合も、原則はまったく同じになります。これは実際にはリリースのスレッド モデルです。初めて触れると理解するのが難しいかもしれませんが、大丈夫です。この絵は、実際に誰もがこの意図を深めていくのに役立ちます。

そして、私の言ったことに従えば、彼の処理プロセス全体も理解できます。皆さんにわかりやすくするために、ここでは例として図を描きます。

現在 KTV があり、この KTV が redis であるとします。

それでは、歌いたいというお客様がたくさんいらっしゃいます。歌いたいのであれば、KTVには必ず従業員がいます。従業員を2つのカテゴリーに分けます。
最初のカテゴリーは玄関の受付係、2 番目のカテゴリーはロビーのマネージャーです。
ドアの受付係は実際にはマルチプレクサーであり、ロビー マネージャーは実際にはファイル アロケーターです。

では、お客様には対応するご要望やニーズがあるはずですので、その際は玄関先の受付スタッフにお願いし、簡単な作業をしていただく必要があります。
ユーザーがどのようなアクティビティに参加したいのか、クーポンがあるのか​​などを知りたいのかもしれません。

そして、玄関先で注文を取る人は、お客様が歌いたいと確信している場合は、後ろに通路がありますので、奥へ行ってくださいと言えます。実はこの通路は行列になっており、この通路に行くために並ぶのです。中に入ると、そこはKTV全体のビジネスホールです。ビジネスホールにはロビーマネージャーが常駐しており、お客様からの実際のご要望にはロビーマネージャーが対応させていただきます。

そして、KTV の 1 つに必ずボックスがあり、各ボックスがユーザーを処理し、顧客からのさまざまなリクエストに対応します。私たちのボックスの中には、ユーザーのさまざまなニーズに対応する 3 人の若い女性または若い兄弟がいます。

たとえば、最初のものは顧客専用にドアを開きます。ドアを開けるという行為は、クライアントとリリースとの間にリンクを確立することに相当します。ドアが開いたら入ってもいいですよね？彼が入社した後は、この若い女性は対応する仕事を担当しなくなり、彼を部下の一人に引き継ぎ、次の若い女性または兄弟が特にユーザー向けのいくつかのリクエストを処理します。

たとえば、顧客が曲をリクエストした場合、曲をリクエストした人はそれに対応する処理を行うように求められます。これを行う方法は、コンピューターの電源を入れて、曲を注文して選択することです。曲を選択したら、顧客に応答する必要があります。あなたにも一理ありますよね？また、マイクをお客様に渡す必要があるので、このときに「こんな若い女性がいます」という通知があり、この若い女性がこのマイクをお客様に渡します。今すぐ歌ってもいいです。この曲はすでに注文してあります。さあ、歌ってください。

この時点で、顧客が曲をリクエストして KTV で歌うというアクション全体が実際に完了します。これは、実際には、以前のリリース スレッド モデルで説明した、クライアントによって実行される操作に対応します。まず接続が確立され、次にリクエストが処理され、次にリクエストの 1 つが応答されます。合計 3 つのステップがあります。

私たちの領域では、ロビー マネージャー全体とその曲リクエストの通知は実際に内部で処理されます。これは私たちのボックスの 1 つに基づいています。ボックスに関しては、Redis ではメモリとして使用できますか。これは、Redis での保存や読み取りなどの操作は実際にはメモリに基づいているためです。したがって、メモリ内にある場合は非常に高速です。

個室であれば、個室で歌ったり、フルーツを注文したり、ビールを飲んだりすることができます。実際、すべての操作が内部ボックスの 1 つに基づいている場合、その一連の動作などは実際には非常に早く完了します。

これは実際、スレッド モデルの 1 つを簡単に理解できるものです。私たちの Redis に関しては、実際にはシングルスレッド モードです。シングルスレッド モデルを使用すると非常に高速になるのはなぜですか?

実際には、主なポイントが 2 つあります。
最初のポイントは、ドア受付係の 1 人が実際にはマルチプレクサーであるということです。このマルチプレクサはノンブロッキング モデルに基づいているため、非常に高速に処理されます。以前のブロック モードにより、応答を 1 つずつ待つことはありません。現在、IO マルチプレクサのようなモデルが使用されているため、その処理パフォーマンスは実際に非常に高速です。

もう 1 つの部分はロビー マネージャーであり、この部分は実際にはメモリに基づいて動作します。純粋なメモリ操作の場合、実際には非常に高速になります。

もちろん、シングルスレッドを使用した上で、その機能の 1 つについても言及しましたが、シングルスレッドを使用すると、マルチスレッドを回避できます。複数のスレッドがある場合、そのコンテキスト スイッチの 1 つを使用できるためです。切り替えると何らかの問題が発生する可能性があります。さらに、それに伴う損失も回避できます。したがって、トランク モデルを使用すると、その同時実行性と効率が非常に高くなります。

推奨される学習: Redis ビデオ チュートリアル

以上がRedis スレッド モデルのグラフィカル分析の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。