Redis がマルチスレッドを導入するのはなぜですか?

1. 問題の概要

Redis 6.0以降のバージョンではシングルスレッドモデルの設計が廃止され、当初シングルスレッドで動作していたRedisも選択的にマルチスレッドを使用するようになりました。モデル 一見、Redis 著者はとても素晴らしいですが、「本当の香りの法則」からは逃れられません。

(1) Redis が最初にシングル スレッド モデルを選択したのはなぜですか (シングル スレッドの利点)?

(2) Redis が 6.0 以降にマルチスレッドを追加したのはなぜですか (場合によっては、シングルスレッドには欠点があり、マルチスレッドで解決できる場合があります)。

実際のところ、著者は真の香りの定理から逃れていないわけではありませんが、時間が経つにつれて、ますます多くの問題が発生します。元のデザインは多少時代遅れになっているため、変更を加える必要があります。 。 OK、質問が 2 つあるので、注意深く分析してみましょう。

2. Redis はなぜ最初からシングルスレッドを使用したのですか?

シングルスレッドであろうとマルチスレッドであろうと、すべては Redis の開発効率を向上させるためです。ベースのデータベースであり、処理する必要があります。多数の外部ネットワーク要求には必然的に複数の IO が必要です。幸いなことに、Redis は多くの優れたメカニズムを使用して高い効率を確保しています。では、なぜ Redis はシングルスレッド モードで設計されているのでしょうか?それは次のように要約できます:

(1) IO 多重化

Redis のトップレベルの設計を見てみましょう。

FD はファイル記述子で、現在のファイルが読み取り可能、書き込み可能、​​または異常であるかどうかを意味します。 I/O 多重化メカニズムを使用して、複数のファイル記述子の読み取り可能および書き込み可能ステータスを同時に監視します。

マルチスレッドの特性を持っていると理解していただければと思います。

ネットワーク リクエストが受信されると、メモリ内で迅速に処理されます。ほとんどの操作は純粋にメモリベースであるため、処理速度は非常に高速になります。 つまり、シングルスレッドモードでは、接続されたネットワーク処理が多くても、IO多重化により高速メモリ処理では無視できるということです。

(2) 高い保守性マルチスレッド モデルはパフォーマンスは良好ですが、プログラムの実行順序に不確実性が生じるため、同時読み取りと書き込みに関連する問題が発生します。 。シングルスレッド モードでは、デバッグとテストが簡単に行えます。

(3) メモリに基づくと、シングルスレッド状態でも効率は高いです。

マルチスレッドでは CPU リソースを最大限に活用できますが、Redis の場合はメモリベースの速度のため、これは非常に高く、1 秒で 100,000 のユーザー リクエストを処理できます。1 秒で 100,000 では不十分な場合は、Redis シャーディング テクノロジを使用して、それを別の Redis サーバーに配信できます。このクッキング方法により、同じ Redis サービス内に多数のマルチスレッド操作が導入されることが回避されます。

AOF バックアップが必要でない限り、この操作はメモリベースであるため、基本的に I/O 操作は必要ありません。これらのデータの読み取りと書き込みはメモリ内でのみ行われるため、処理速度は非常に高速です。すべての外部リクエストを処理するためにマルチスレッド モデルを使用することは、良い解決策ではない可能性があります。

基本的に 2 つの文に要約できることがわかりました。メモリに基づいており、多重化テクノロジを使用しています。シングルスレッドの速度は非常に速く、マルチスレッドの特性が保証されています。マルチスレッドを使用する必要がないためです。

3. マルチスレッドを導入する理由は何ですか? シングルスレッドの利点については先ほど述べましたが、ここではなぜマルチスレッドを導入し、マルチスレッドの不快感を克服する必要があるのか​​について話したいと思います。マルチスレッドの導入により、Redis のいくつかの側面ではシングルスレッドの利点が失われていることがわかります。

読み取り/書き込みシステムの呼び出しは、Redis の実行中にネットワークの読み取りと書き込みを要求するため、CPU 時間のほとんどを占めるため、ネットワークの読み取りと書き込みをマルチスレッドにすると、パフォーマンスが大幅に向上します。

Redis のマルチスレッドは、ネットワーク データの読み書きとプロトコル解析にのみ使用されますが、コマンドの実行は依然としてシングルスレッドです。この設計の理由は、マルチスレッドによって Redis が複雑になることを望まないことと、キー、LUA、トランザクション、LPUSH/LPOP などの同時実行性の問題を制御する必要があるためです。

Redis の最新バージョンでは、他のスレッドによって非同期に処理できるいくつかの削除操作が追加されました (前述の

UNLINK

と

FLUSHALL ASYNC##)。 ##FLUSHDB ASYNC

、なぜこれらの削除操作が必要なのでしょうか?また、マルチスレッドで非同期に処理する必要があるのはなぜですか? Redis では del コマンドを使用して要素を削除できることがわかっていますが、要素が非常に大きい場合 (数十メガバイトまたは数百メガバイトを占める可能性がある)、短時間では完了できません。 、マルチスレッド非同期サポートが必要です。 削除作業をバックグラウンドで実行できるようになりました。

以上がRedis がマルチスレッドを導入するのはなぜですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。