Redis の面接で知っておくべき 20 個以上の質問をまとめました。ぜひ集めてください。！-Redis-php.cn

この記事では、ギャップを確認して埋め、知識ポイントを向上させることができるように、Redis の面接での質問をいくつか紹介します。一定の参考値があるので、困っている友達が参考になれば幸いです。

Redis の面接で知っておくべき 20 個以上の質問をまとめました。ぜひ集めてください。！

#アプリケーションシナリオ

キャッシュ
共有セッション
メッセージキューシステム
分散ロック

シングルスレッド Redis が速い理由

純粋なメモリ操作
シングルスレッド-threaded Redis スレッド操作により、頻繁なコンテキスト切り替えが回避されます
合理的かつ効率的なデータ構造
ノンブロッキング I/O 多重化メカニズムを採用します (データの到着を同時に複数のファイル記述子を監視する 1 つのファイル記述子)

##Redis のデータ構造と使用シナリオ

String string: 文字列型は Redis の最も基本的なデータ構造です。まず第一に、キーはすべて文字列型であり、他のいくつかのデータ構造は文字列型に基づいて構築されます。私たちはよく set The key を使用します。 value コマンドは文字列です。キャッシュ、カウント、共有セッション、レート制限などで一般的に使用されます。

ハッシュハッシュ: Redis では、ハッシュタイプは、キーと値のペア構造であるキー値自体を指します。ハッシュは、ショッピングの実装など、ユーザー情報を保存するために使用できます。カート。
リストリスト (二重リンクリスト): リスト (リスト) タイプは、複数の順序付けされた文字列を格納するために使用されます。簡単なメッセージキュー機能を実行できます。
Set コレクション: set (セット) タイプは、複数の文字列要素を保存するためにも使用されますが、リストタイプとは異なり、セット内で重複した要素は許可されず、セットの要素はin は順序付けされていないため、インデックス添字を通じて取得できません。 Set の交差、和集合、差分などの演算を使用して、共通の設定、すべての設定、独自の設定、その他の関数を計算できます。
ソートセット順序セット (ジャンプリストの実装): ソートセットには追加の重みパラメータースコアがあり、セット内の要素はスコアに従って配置できます。 TOP N の操作を実行するためのランキングアプリケーションとして使用できます。

Redis のデータ有効期限戦略は、定期削除と遅延削除

戦略を採用しています

定期的な削除戦略: Redis では、タイマーですべてのキーを定期的に監視して、キーの有効期限が切れているかどうかを判断し、有効期限が切れた場合は削除します。この戦略では、期限切れのキーは最終的に確実に削除されますが、重大な欠点もあります。毎回メモリ内のすべてのデータを走査するため、大量の CPU リソースが消費されます。また、キーの期限が切れてもタイマーがまだ有効である場合があります。覚醒していない状態でも、キーはこの間も使用できます。

遅延削除戦略: キーを取得するときは、まずキーの有効期限が切れているかどうかを確認し、有効期限が切れている場合はキーを削除します。この方法には欠点があり、キーが使用されていない場合は常にメモリ内に存在し、実際には有効期限が切れているため、多くのスペースが無駄になります。
これら 2 つの戦略は当然補完的です。結合後、スケジュールされた削除戦略にはいくつかの変更が加えられました。毎回すべてのキーをスキャンするのではなく、キーの一部をランダムに選択します。チェックが実行されるため、CPU リソースの消費が削減されます。遅延削除戦略は、チェックされていないキーを補完し、基本的にすべての要件を満たします。しかし、時々、タイマーによって抽出されず、使用されないこともあるのですが、このデータはどのようにしてメモリから消えるのでしょうか?どうでもいいですが、メモリの消去機構もありますので、メモリが足りない場合にはメモリの消去機構が働きます。排除戦略は次のように分けられます。メモリが新しく書き込まれたデータを収容するのに十分でない場合、新しい書き込み操作はエラーを報告します。 (Redis のデフォルトポリシー) 新しく書き込まれたデータを収容するにはメモリが不十分な場合、キー空間で、最も最近使用されていないキーを削除します。 (LRU 推奨) メモリが新しく書き込まれたデータを収容するのに十分でない場合、キーはキー空間からランダムに削除されます。新たに書き込まれるデータを収容するのにメモリが不十分な場合、有効期限が設定されたキー空間では、最も最近使用されていないキーが削除されます。この状況は通常、Redis がキャッシュと永続ストレージの両方として使用される場合に使用されます。メモリが新しく書き込まれたデータを収容するのに不十分な場合、キーは有効期限が設定されてキー空間からランダムに削除されます。新たに書き込まれるデータを収容するのにメモリが不十分な場合、有効期限が設定されたキー空間では、有効期限が早いキーが最初に削除されます。

Redis の set および Redis の setnx

setnx は有効期限の設定をサポートしていません。分散ロックを実行するときは、特定のクライアントが中断されるのを避ける必要があります。ロックの場合は、ロックの有効期限を設定する必要があります。同時実行性が高い場合、Setnx と Expir はアトミック操作を実装できません。これを使用したい場合は、プログラムコードでロックを表示する必要があります。 SETNX の代わりに SET を使用することは、SETNX EXPIRE がアトミック性を達成することと同等であり、SETNX が成功し、EXPIRE が失敗することを心配する必要はありません。

Redis の LRU の具体的な実装:

従来の LRU はスタックを使用します。毎回、最後に使用されたものがスタックの先頭に移動されますが、その結果、select * 実行時にヘッダーデータに非ホットデータが大量に占有されるため、改善が必要です。 Redis はキーによって値を取得するたびに、値の lru フィールドを現在の第 2 レベルのタイムスタンプに更新します。 Redis の初期実装アルゴリズムは非常に単純で、辞書から 5 つのキーがランダムに取得され、lru フィールド値が最も小さいものが削除されます。 3.0 では、アルゴリズムの別のバージョンが改良され、最初にランダムに選択されたキーがプールに配置されます (プールのサイズは 16)。プール内のキーは LRU サイズの順に配置されます。次に、ランダムに選択された各 keylru 値は、プールがいっぱいになるまで追加され続ける前に、プール内の最小の lru より小さくなければなりません。いっぱいになった後は、新しいキーを挿入する必要があるたびに、プール内で最大の lru を持つキーを取り出す必要があります。削除する場合は、プールから最小 lru 値を直接選択して削除します。

Redis がホットキーを検出する方法

経験に基づいて予測します。たとえば、アクティビティの開始が事前にわかっている場合は、次のようにします。次に、このキーをホットスポットキーとして使用します。
サーバー側の収集: Redis を操作する前に、データ統計用のコード行を追加します。
評価用のパケットのキャプチャ: Redis はクライアントとの通信に TCP プロトコルを使用します。通信プロトコルは RESP を使用するため、パケットを監視する独自のプログラムを作成することで、分析のためにパケットをインターセプトすることもできます。ポート。
プロキシ層では、各 Redis リクエストが収集され、報告されます。
Redis にはコマンドクエリが付属しています。Redis4.0.4 バージョンでは、ホットキーを見つけるための redis-cli –hotkeys が提供されます。 (Redis 独自のコマンドを使用してクエリを実行する場合は、最初にメモリエビクションポリシーを allkeys-lfu または volatile-lfu に設定する必要があることに注意してください。そうしないと、エラーが返されます。Redis に入り、config set maxmemory-policy allkeys を使用します。 -lfu.)

Redis のホットスポットキーソリューション

サーバー側キャッシュ: ホットスポットデータをサーバーのメモリにキャッシュする(Redis に付属のメッセージ通知メカニズムを使用して、Redis とサーバーのホットスポットキー間のデータの一貫性を確保し、ホットスポットキークライアントのモニターを確立します。ホットスポットキーが更新されると、サーバーもそれに応じて更新されます。)
Backup Hotspot Key: ホットスポットキーの乱数を他の Redis ノードにランダムに配布します。このようにすると、ホットスポットキーにアクセスするときに、すべてが同じマシンにアクセスすることはなくなります。

Redis キャッシュ雪崩問題を解決する方法

Redis 高可用性アーキテクチャを使用する: Redis クラスターを使用して、 Redis サービスがクラッシュしないことを確認します。
キャッシュ時間に一貫性がありません。集団的な障害を避けるために、キャッシュの有効期限にランダムな値を追加します。
現在の制限付きダウングレード戦略: 特定の申請があります。たとえば、パーソナライズされたレコメンデーションサービスは利用できなくなりました。ホットデータレコメンデーションサービスに置き換えられます

解決方法Redis キャッシュの侵入の問題

インターフェイスで確認
#null 値を保存 (キャッシュのブレークダウンとロック、または期限切れにならないように設定) )
ブルームフィルターインターセプト: 最初にすべての可能なクエリキーをブルームフィルターにマッピングします。クエリを実行するときは、まずブルームフィルターにキーが存在するかどうかを確認し、存在する場合は実行を続行します。存在しない場合は直接返されます。ブルームフィルターは値を複数のハッシュビットに格納するため、ブルームフィルターが特定の要素が存在すると判断した場合、それを誤って判断する可能性があります。ブルームフィルターが要素が存在しないと判断した場合、その要素は存在しないはずです。

Redis の永続化メカニズム

効率を確保するために、Redis はデータをメモリにキャッシュしますが、データは定期的に更新されます。または、追加されたレコードファイルに変更操作を書き込んで、データの永続性を確保します。 Redis には 2 つの永続化戦略があります。

RDB: スナップショット形式は、メモリ内のデータをダンプファイルに直接保存し、定期的に保存し、戦略を保存します。 Redis を永続化する必要がある場合、Redis は子プロセスをフォークし、子プロセスはディスク上の一時 RDB ファイルにデータを書き込みます。子プロセスが一時ファイルの書き込みを完了したら、元の RDB を置き換えます。
AOF: Redis サーバーを変更するすべてのコマンドを、コマンドのコレクションであるファイルに保存します。

永続化には AOF を使用します。各書き込みコマンドは、書き込み関数を通じて appendonly.aof に追加されます。 aof のデフォルトポリシーは 1 秒に 1 回 fsync することになっており、この構成では障害が発生しても最大 1 秒間はデータが失われます。欠点は、同じデータセットの場合、通常、AOF のファイルサイズが RDB ファイルのサイズよりも大きいことです。使用される fsync 戦略によっては、AOF が RDB よりも遅くなる場合があります。 Redis はデフォルトでスナップショット RDB の永続化方式を使用します。マスタとスレーブの同期は、マスタとスレーブが接続されたばかりの場合は完全同期（RDB）が実行され、完全同期が完了するとインクリメンタル同期（AOF）が実行されます。

Redis トランザクション

Redis トランザクションの本質は一連のコマンドです。トランザクションは一度に複数のコマンドの実行をサポートしており、トランザクション内のすべてのコマンドはシリアル化されます。トランザクション実行処理中、キュー内のコマンドは順番に実行され、他のクライアントから送信されたコマンド要求はトランザクション実行コマンドシーケンスに挿入されません。要約すると、redis トランザクションは、キュー内の一連のコマンドを 1 回限り、順次、排他的に実行します。
Redis トランザクションには分離レベルの概念がありません。バッチ操作は、EXEC コマンドを送信する前にキューキャッシュに入れられ、実際には実行されません。トランザクション内にクエリはありません。トランザクション内の更新は、トランザクション外のクエリでは参照できません。
Redis では、単一のコマンドがアトミックに実行されますが、トランザクションはアトミックであることが保証されず、ロールバックはありません。トランザクション内のいずれかのコマンドが実行に失敗した場合でも、残りのコマンドは引き続き実行されます。

Redis トランザクション関連コマンド

watch key1 key2... : 1 つ以上のキーを監視します。トランザクションが実行されると、監視対象のキーが他のコマンドによって変更されると、トランザクションは中断されます (オプティミスティックロックと同様)
#multi: トランザクションブロックの開始をマークします (キューに入れられます)。
exec: すべてのトランザクションブロックのコマンドを実行します (exec が実行されると、以前に追加された監視ロックはキャンセルされます)
#discard:トランザクションをキャンセルし、あきらめますトランザクションブロック内のすべてのコマンド
unwatch: すべてのキーの監視の監視をキャンセルします

次の違いRedis と memcached

ストレージ方式に関して: memcache はすべてのデータをメモリに保存し、停電後にハングアップします。データはメモリサイズを超えることはできません。 Redis の一部のデータはハードディスクに保存されるため、データの耐久性が保証されます。
データサポートの種類に関して: memcache はデータ型を単純にサポートし、単純なキーと値のみをサポートしますが、redis は 5 つのデータ型をサポートします。
基礎となるモデルは異なります。つまり、基礎となる実装メソッドとクライアントと通信するためのアプリケーションプロトコルが異なります。一般的なシステムがシステム関数を呼び出すと、移動やリクエストに一定の時間が無駄になるため、Redis は独自の VM メカニズムを直接構築しました。
値のサイズ: redis は 1 GB に達する可能性がありますが、memcache はわずか 1 MB です。

#Redis の複数のクラスターモード

#マスター/スレーブレプリケーション

Sentinel モード
クラスターモード

センチネルは分散システムです、マスター/スレーブレプリケーションに基づいて、アーキテクチャ内で複数のセンチネルプロセスを実行できます。これらのプロセスは、噂プロトコルを使用してマスターがオフラインかどうかに関する情報を受け取り、投票プロトコルを使用して自動フェイルオーバーを実行するかどうかを決定し、どのスレーブを選択するかを決定します。新しいマスターを務めます。

各セントリーは、他のセンチネル、マスター、スレーブに定期的にメッセージを送信し、相手が生存しているかどうかを確認します。相手が指定時間 (設定可能) 以内に応答しないことが判明した場合は、相手が電話を切ったように一時的にみなします（いわゆる「主観的にはダウンしたとみなされる」）。

「センチネルグループ」のほとんどのセンチネルが、特定のマスターが応答しないと報告した場合、システムはマスターが「完全に停止している」(つまり、客観的には実際にダウンしたマシンである) とみなします。 , 残りのスレーブノードからマスターに昇格するノードを選択し、関連する構成を自動的に変更します。

Redis の再ハッシュ

Redis の再ハッシュ操作は 1 回限りの集中的な方法で完了するのではなく、複数の段階的な手順で完了します。リハッシュの進行状況を示すカウンタ変数 rehanadx。

この種のプログレッシブなリハッシュは、集中型のリハッシュによって引き起こされる膨大な量の計算とメモリ操作を回避しますが、redis がリハッシュされる場合、通常のアクセスリクエストはハッシュテーブルに 2 回アクセスする必要がある場合があることに注意してください ( ht[0], ht [1])、たとえば、キー値を新しい ht1 に再ハッシュする場合、最初に ht0 にアクセスする必要があります。ht0 で見つからない場合は、ht1 で見つかります。

Redis ハッシュテーブルの拡張条件

ハッシュテーブルに保存されるキーの数がハッシュテーブルのサイズを超えています。
Redis サーバーは現在 BGSAVE コマンド (rdb) または BGREWRITEAOF コマンドを実行しておらず、ハッシュテーブルの負荷係数は 1 以上です。
Redis サーバー BGSAVE コマンド (rdb) または BGREWRITEAOF コマンドが実行中であり、ハッシュテーブルの負荷率が 5 以上です。 (負荷率 = 保存されたノード数)ハッシュテーブル / ハッシュテーブルのサイズで、ハッシュテーブルの負荷率が 0.1 未満の場合、ハッシュテーブルに対して縮小操作を実行します。)

Redis 同時競合キーのソリューション

分散ロックタイムスタンプ
メッセージキューの使用

Redis パイプライン

シングルスレッドブロッキング Redis の場合、パイプラインはバッチ操作に対応し、複数のコマンドを Redis サーバーに継続的に送信し、応答結果を 1 つずつ解析できます。パイプライン化によりバッチ処理のパフォーマンスが向上します。向上の主な理由は、TCP 接続における「対話の往復」時間が短縮されることです。パイプラインの最下層はすべての操作をストリームにカプセル化し、redis は独自の受信および送信出力ストリームを定義します。 sync() メソッドで操作を実行します。各リクエストはキューに入れられ、応答パケットが解析されます。