シングルスレッドを使用すると Redis がなぜこれほど高速になるのでしょうか?

Redis はなぜ単一スレッドを使用するのですか?

マルチスレッドのオーバーヘッド

適切なシステム設計がない場合、マルチスレッドを使用すると、通常、右側に示す結果が得られます (縦軸に注意してください)。最初にスレッド数を増やすと、システムのスループット レートは増加しますが、さらにスレッド数を増やすと、システムのスループット レートはゆっくりと増加するか、場合によっては減少します。

主なボトルネックは次のとおりです: 通常、システムには複数のスレッドによって同時にアクセスされる共有リソースが存在します。共有リソースの正確性を確保するには、追加のロックなどのスレッドのセキュリティを確保するには、追加のオーバーヘッドが伴うメカニズムが必要です。

たとえば、最も一般的に使用される List タイプを例に挙げます。Redis がマルチスレッド設計を採用しており、2 つのスレッド A と B が List で を実行していると仮定します。 LPUSH および LPUSH 操作では、実行するたびに同じ結果、つまり [A スレッドが置いたデータを B スレッドが取り出す] を達成するために、次のようにします。 2 つのプロセスを連続して実行する必要があります。これは、マルチスレッド プログラミング モデルが直面する共有リソースの同時アクセス制御の問題です。

同時アクセス制御は、マルチスレッド開発において常に難しい問題でした。単純にミューテックスを使用した場合、スレッドが追加されたとしても、ほとんどのスレッドは待機状態になります。ミューテックスロックを取得すると並列が直列になるため、スレッドが増加してもシステムのスループットレートは向上しません。

同時に、同時アクセス制御を追加すると、システム コードの可読性と保守性も低下するため、Redis は単純にシングル スレッド モードを採用します。

単一スレッドを使用すると、Redis がこれほど高速になるのはなぜですか?

単一スレッドが使用される理由は、Redis 設計者のさまざまな側面からの評価の結果です。

• Redis のほとんどの操作はメモリ内で完了します

• ハッシュ テーブルやスキップ テーブルなどの効率的なデータ構造の使用

• 多重化メカニズムを採用することで、ネットワーク IO 操作で多数のクライアント要求を同時に処理し、高いスループットを実現できます

Redis は IO に単一のスレッドを使用するため、スレッドがブロックされている場合、スレッドを多重化することはできないため、Redis がネットワークおよび IO 操作における潜在的なブロック ポイントを考慮して設計されているに違いないことは想像に難くありません。

ネットワークおよび IO 操作の潜在的なブロックポイント

ネットワーク通信では、Get リクエストを処理するために、サーバーはクライアント リクエスト (

bind/listen##) をリッスンする必要があります。 #)、クライアントは接続を確立し (accept)、ソケットからリクエストを読み取り (recv)、クライアントによって送信されたリクエストを解析します (parse) )、最後にクライアント Result(send) に返します。 最も基本的なシングルスレッド実装は、上記の操作を順番に実行することです。

上記の赤でマークされた accept および recv 操作は、潜在的なブロックポイントです:

Redis が接続リクエストを監視する場合、しかし、接続は正常に確立できません。
• accept()

  関数でブロックされ、現時点では他のクライアントは Redis との接続を確立できません。

いつRedis は
• recv()

  を通じてクライアントからデータを読み取ります。データが到着していない場合は常にブロックされます

多重化 IO モデルに基づく高パフォーマンス

IO のブロッキング問題を解決するために、Redis は Linux IO 多重化メカニズムを採用しています。これにより、複数のリスニング ソケットと接続されたソケットがカーネル内に同時に存在できるようになります (

select/epoll

)。 カーネルは、これらのソケット上の接続またはデータ要求を常にリッスンします。 Redis は受信リクエストを処理するため、1 つのスレッドが複数の IO ストリームを処理する効果が得られます。

現時点では、Redis スレッドは特定のクライアント要求の処理でブロックされないため、同時に複数のクライアントに接続して要求を処理できます。

コールバックメカニズム

select/epoll リクエストが FD に到着したことを検出すると、対応するイベントがトリガーされてキューに入れられ、Redis スレッドはイベント キューを継続的に処理します。イベントベースのコールバックが実装されています。

たとえば、Redis は、Accept および Read イベントの

accept

および get コールバック関数を登録します。 Linux カーネルが接続リクエストまたはデータ読み取りリクエストを監視すると、Accept イベントと Read イベントがトリガーされ、このとき、カーネルは対応する accept と get をコールバックします。 Redisの機能を扱います。 Redis のパフォーマンス ボトルネック

上記の分析後、多重化メカニズムを通じて複数のクライアント リクエストを同時に監視できますが、Redis には依然としてパフォーマンス ボトルネックがいくつかあります。それは日常のプログラミングでは避ける必要があります。

1. 時間のかかる操作

Redis でリクエストに長時間かかると、サーバー全体のパフォーマンスに影響します。後続のリクエストは、時間のかかる前のリクエストが処理されるまで待つ必要があります。

ビジネス シナリオを設計するときは、これを回避する必要があります。Redis の lazy-free メカニズムでは、実行のために非同期スレッドでメモリを解放するという時間のかかる操作も行われます。

2. 高同時実行シナリオ

同時実行の量が非常に多い場合、IO 多重化メカニズムが使用されていますが、クライアント IO データのシングルスレッド読み取りおよび書き込みにパフォーマンスのボトルネックが発生します。クライアントのデータを順番に読み取る場合、複数の CPU コアを利用することはできません。

6.0 の Redis は、CPU マルチコアとマルチスレッドを使用してクライアント データの読み取りと書き込みを行うことができますが、並列処理されるのはクライアントの読み取りと書き込みだけであり、各コマンドの実際の操作は依然としてシングルスレッドです。 。

Redis に関連するその他の興味深い質問

この機会に、Redis に関連するいくつかの興味深い質問もしてください。

• なぜ Redis を使うのですか? メモリに直接アクセスするのは悪いことではないでしょうか?

これは実際にはあまり明確に定義されていません。頻繁に変更されない一部のデータについては、メモリに直接配置できます。Redis に配置する必要はありません。メモリに入れることができます。データの更新時に一貫性の問題が発生する可能性があります。つまり、1 つのサーバー上のデータのみが変更される可能性があるため、データはローカル メモリにのみ存在します。 Redis サーバーにアクセスすると、Redis を使用して整合性の問題を解決できます。

• データが多すぎてメモリに保存できない場合はどうすればよいですか?たとえば、100G のデータをキャッシュしたい場合はどうすればよいでしょうか?

ここにも広告があります Tair はタオバオのオープンソース分散 KV キャッシュ システムです Redis の豊富な操作を継承しています 理論的には総データ量は無制限です 使いやすさを目指しています拡張性と信頼性も向上しています。興味のある方はぜひご覧ください~

以上がシングルスレッドを使用すると Redis がなぜこれほど高速になるのでしょうか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。