Redis 6.0 安定バージョン
Redis 6.0.0 安定バージョンには、新しいネットワーク プロトコル RESP3 など、多くの新機能と機能改善が含まれています。新しいクラスターエージェント、ACLなど。皆さんが一番気になるのはやはり「マルチスレッド」ではないかと思いますが、redis 6.0バージョンの新機能を見ていきましょう。
(学習ビデオ共有: redis ビデオ チュートリアル )
1. Redis6.0 より前のバージョンは本当にシングルスレッドですか?
Redis が取得 (ソケット読み取り)、解析、実行、コンテンツ返却 (ソケット書き込み) などを含むクライアント リクエストを処理する場合、それらはすべてシーケンシャルでシリアルなメイン スレッドによって処理されます。いわゆる「シングルスレッド」です。ただし、厳密に言えば、Redis 4.0 以降はシングルスレッドではなく、メイン スレッドに加えて、ダーティ データのクリーニング、不要な接続の解放、大きなキーの削除など、低速の操作を処理するバックグラウンド スレッドもあります。
2. Redis6.0 より前にマルチスレッドが使用されなかったのはなぜですか?
公式は同様の質問に答えています: Redis を使用する場合、CPU がボトルネックになる状況はほとんどありません。Redis は主にメモリとネットワークによって制限されます。たとえば、通常の Linux システムでは、Redis はパイプライン処理を使用して 1 秒あたり 100 万のリクエストを処理できるため、アプリケーションが主に O(N) または O(log(N)) コマンドを使用する場合、CPU をほとんど消費しません。
シングルスレッド化後のメンテナンス性は高いです。マルチスレッド モデルはいくつかの側面では良好なパフォーマンスを示しますが、プログラムの実行順序に不確実性が生じ、同時読み取りと書き込みに関する一連の問題が発生し、システムの複雑さが増大し、スレッドの切り替えやロックが発生する場合もあります。ロック解除とデッドロックによって。 RedisはAEイベントモデルやIO多重化などの技術により非常に高い処理性能を持っているため、マルチスレッドを使用する必要がありません。シングルスレッドメカニズムにより、Redis の内部実装の複雑さが大幅に軽減され、Hash の慣性、Rehash、Lpush およびその他の「スレッド安全でない」コマンドをロックなしで実行できます。
3.Redis6.0 でマルチスレッドが導入されるのはなぜですか?
Redis はすべてのデータをメモリに配置します。メモリの応答時間は約 100 ナノ秒です。小さなデータ パケットの場合、Redis サーバーは 80,000 ～ 100,000 QPS を処理できますが、これは Redis 処理の限界でもあります80% の企業では、シングルスレッドの Redis で十分です。
しかし、ビジネス シナリオがますます複雑になるにつれ、一部の企業ではトランザクション量が簡単に数億に達する可能性があるため、より大きな QPS が必要になります。一般的なソリューションは、分散アーキテクチャでデータを分割し、複数のサーバーを使用することですが、このソリューションには、管理するには Redis サーバーが多すぎたり、メンテナンス コストが高かったりするなど、非常に大きな欠点があります。ソリューションによっては、単一の Redis サーバーに適しているものもあります。データ パーティションでは機能しない、データ パーティションではホットスポットの読み取り/書き込みの問題を解決できない、データ スキュー、再割り当て、スケールアップ/ダウンがより複雑になる、などです。
Redis 自体の観点から見ると、読み取り/書き込みシステムは Redis の実行中にネットワークの読み取りと書き込みを要求するために CPU 時間のほとんどを占めるため、ボトルネックは主にネットワークの IO 消費にあります。最適化の 2 つの主な方向性:
• ネットワーク IO パフォーマンスの向上。一般的な実装には、DPDK を使用してカーネル ネットワーク スタックを置き換えることが含まれます。
• マルチスレッドを使用して、マルチコアを完全に活用します。一般的な実装には、Memcached が含まれます。
このプロトコル スタックの最適化方法は Redis とはあまり関係がありませんが、マルチスレッドをサポートすることが最も効果的で便利な操作方法です。要約すると、redis は 2 つの主な理由でマルチスレッドをサポートします:
• サーバーの CPU リソースを最大限に活用できます。現在、メインスレッドは 1 つのコアのみを使用できます。
• マルチスレッド タスクは、 Load
4.Redis6.0 はデフォルトでマルチスレッドを有効にしますか?
Redis6.0 のマルチスレッドはデフォルトで無効になっており、メインスレッドのみが使用されます。これを有効にしたい場合は、redis.conf 設定ファイルを変更する必要があります: io-threads-do-reads yes
5. Redis6.0 マルチスレッドの場合が有効になっている場合、スレッド数を設定するにはどうすればよいですか?
マルチスレッドを有効にした後、スレッド数を設定する必要があります。そうしないと有効になりません。 redis.conf 構成ファイルも変更します。 
スレッド数の設定に関しては、公式の提案があります: 4 コア マシンは 2 または 3 スレッドに設定することをお勧めします。コア マシンは 6 スレッドに設定することをお勧めします。スレッドの数はマシンのコアの数よりも小さくする必要があります。スレッド数は多ければ多いほど良いことにも注意が必要で、当局は 8 スレッドを超えると基本的に意味がないと考えています。
6. Redis6.0 でマルチスレッドが採用された後のパフォーマンス向上効果は何ですか?
Redis 作者 antirez が RedisConf 2019 での共有時に言及しました: Redis 6 に導入されたマルチスレッド IO 機能により、パフォーマンスが少なくとも 2 倍向上します。国内の専門家も不安定版を使用して Alibaba Cloud esc のテストを実施し、4 スレッド IO での GET/SET コマンドのパフォーマンスは、シングル スレッドの場合と比較してほぼ 2 倍になりました。 ＃＃＃＃＃＃＃＃＃テスト環境＃＃＃：＃＃＃
Redis サーバー: Alibaba Cloud Ubuntu 18.04、8 CPU 2.5 GHZ、8G メモリ、ホスト モデル ecs.ic5.2xlarge
Redis ベンチマーク クライアント: Alibaba Cloud Ubuntu 18.04、8 2.5 GHZ CPU、8G メモリ、ホストモデル ecs.ic5.2xlarge
テスト結果:
詳細については、https://zhuanlan.zhihu を参照してください。 com/p /76788470
注 1: これらのパフォーマンス検証テストでは、厳密な遅延制御やさまざまな同時実行シナリオでのストレス テストは実行されません。データは検証の参考のみを目的としており、オンライン指標として使用することはできません。
注 2: マルチスレッドを有効にする場合は、少なくとも 4 コアのマシンを使用することをお勧めしますが、Redis インスタンスがかなりの量の CPU 時間を占有しています。そうでない場合は、マルチスレッドを使用する意味がありません。 -糸通し。したがって、企業の開発者の 80% は一見するだけだと推定されています。
7.Redis6.0 マルチスレッド実装メカニズム?
#プロセスは次のように簡単に説明されます:
1. メイン スレッドは、接続の確立を受信する責任があります。リクエストを実行し、ソケットを取得してグローバルに配置します。 読み取り処理キューを待機しています 2. メイン スレッドが読み取りイベントを処理した後、RR (ラウンド ロビン) を通じてこれらの接続をこれらの IO スレッドに割り当てます
3。メイン スレッドはブロックし、IO スレッドがソケットの読み取りを完了するのを待ちます
4 。メイン スレッドはリクエスト コマンドをシングルスレッド方式で実行し、リクエストされたデータは読み取られて解析されますが、実行されません。 5. メインスレッドはブロックし、IO スレッドがデータをソケットに書き戻すのを待ちます。
6. バインドを解除し、待機キューをクリアします。
(画像ソース: https://ruby -china.org/topics/38957)
この設計には次の特徴があります:
2. IOスレッドはソケット解析コマンドの読み書きのみを担当し、コマンド処理は担当しません
上記の実装メカニズムからわかるように、Redis のマルチスレッド部分はネットワーク データの読み書きとプロトコル解析の処理にのみ使用され、コマンドの実行は引き続き実行されます。単一のスレッドで順次実行されます。したがって、キー、Lua、トランザクション、LPUSH/LPOP などの制御に関する同時実行性やスレッドの安全性の問題を考慮する必要はありません。
9. Linux 環境に Redis6.0.1 (6.0 の正式バージョンは 6.0.1) をインストールするにはどうすればよいですか?これは、他のバージョンの Redis をインストールするのと何ら変わりません。プロセス全体に落とし穴はないため、ここでは説明しません。唯一注意すべき点は、設定されたマルチスレッドの数が CPU のコア数よりも小さくなければならないということです。コマンド
[root@centos7.5 ~]# lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 4 On-line CPU(s) list: 0-3
過去数年間、memcached は大手インターネット企業で一般的に使用されていたキャッシュ ソリューションでした。は基本的に、キャッシュに関して面接官にとって必須の面接質問となっていますが、近年では memcached の使用は減り、基本的にはすべて redis です。ただし、Redis 6.0 にマルチスレッド機能が追加されても、同様の問題が依然として発生する可能性があるため、次に、マルチスレッド モデルの簡単な比較のみを行います。
上の図に示すように、Memcached サーバーはマスター ワーカー モードで動作し、サーバーはソケットを使用してクライアントと通信します。メインスレッドとワーカースレッドは通信にパイプを使用します。メインスレッドは libevent を使用して listen および accept の読み取りイベントを監視し、イベントが応答した後、接続情報のデータ構造をカプセル化し、アルゴリズムに従って適切な作業スレッドを選択し、接続情報を運ぶ接続タスクを配布します。対応するスレッドは接続記述子を使用して確立し、クライアントのソケットが接続して後続のデータ アクセス操作を実行します。
Redis6.0 と Memcached マルチスレッド モデルの比較:
類似点: どちらもマスター スレッド - ワーカー スレッド モデルを採用しています 異なる点: Memcached はメイン ロジックをワーカー スレッドで実行します。このモデルはシンプルで、真のスレッド分離を実現し、スレッド分離に関する従来の理解に準拠しています。 Redis は処理ロジックをマスター スレッドに返すため、モデルの複雑さはある程度増加しますが、スレッドの同時実行セキュリティなどの問題も解決されます。
マルチスレッドの機能に関して、Antirez はかつて 6.0 RC1 で説明しました:
Redis がマルチスレッドをサポートするには 2 つの実現可能な方法があります。1 つ目は「memcached」のようなものです。こうすることで、Redis インスタンスは複数のスレッドを開くため、GET/SET などの単純なコマンドで 1 秒あたりに実行できる操作の数が増加します。これには、I/O やコマンド解析などのマルチスレッド処理が含まれるため、「I/O スレッド」と呼ばれます。もう 1 つは、他のクライアントがブロックされないように、遅いコマンドを別のスレッドで実行できるようにすることです。このスレッド モデルを「遅いコマンド スレッド」と呼びます。
慎重に検討した結果、Redis は「I/O スレッド」を使用しません。Redis は実行時に主にネットワークとメモリの影響を受けるため、Redis のパフォーマンスの向上は主に複数の Redis インスタンス、特に Redis クラスターを通じて行われます。次に、主に 2 つの側面の改善を検討します。
1. Redis クラスターの複数のインスタンスは、オーケストレーションを通じてローカル インスタンスのディスクを合理的に使用して、AOF の同時書き換えを回避できます。
2. より適切なクラスター プロトコル クライアントがない場合にユーザーがクラスターを抽象化できるように、Redis クラスター プロキシを提供します。
補足ですが、Redisはmemcachedと同じメモリシステムですが、Memcachedとは異なります。マルチスレッドは複雑なので、単純なデータ モデルを考慮する必要があり、LPUSH を実行するスレッドは、LPOP を実行する他のスレッドにサービスを提供する必要があります。
私が本当に期待しているのは、実際には「遅い操作のスレッド化」です。redis6 または redis7 では、スレッドが遅い操作を処理するためにキーを完全に制御できるように、「キーレベルのロック」が提供されます。
参照: http://antirez.com/news/126
12. IO 多重化については、Redis スレッドでよく言及されます。
これは IO モデルの一種であり、古典的な Reactor 設計パターンであり、非同期ブロッキング IO とも呼ばれます。 
マルチチャネルとは複数のソケット接続を指し、再利用とは 1 つのスレッドを再利用することを指します。主な多重化テクノロジには、select、poll、epoll の 3 つがあります。 epoll は、利用可能な最新かつ最高の多重化テクノロジです。マルチチャネル I/O 多重化テクノロジの使用により、単一のスレッドで複数の接続リクエストを効率的に処理でき (ネットワーク IO の時間消費を最小限に抑えます)、Redis はメモリ内のデータを非常に高速に処理します (ここではメモリ内操作は問題になりません) ).パフォーマンスのボトルネック)、主に上記 2 点が Redis の高スループットに貢献します。
13. Redis のイースターエッグ LOLWUT をご存知ですか?
これは実際には Redis 5.0 から存在していますが、知っているだけでごめんなさい。著者はこの機能を「LOLWUT: データベース コマンド内の芸術作品」、「データベース コマンド内の芸術作品」と表現しています。それを感情と呼ぶこともできますし、イースターエッグと呼ぶこともできますが、それが具体的に何であるかは明かしません。私と同じように、それが何であるかを知らない友人は、http://antirez.com/news/123 を参照してください。実行するたびにランダムに生成されます。 
関連する推奨事項: redis データベース チュートリアル
以上がRedis バージョン 6.0 の新機能の紹介の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
