Redis: 面接でよくある質問と回答

1.Redisとは何ですか? 主な用途は何ですか?

回答: Redis は、データベース、キャッシュ、メッセージブローカーとして使用できるオープンソースのメモリ内データ構造ストレージシステムです。文字列、リスト、ハッシュテーブル、セット、ソートセットなどのさまざまなデータ構造をサポートします。Redis の主な用途には、キャッシュ、セッションストレージ、リーダーボード、カウンター、パブリッシュ/サブスクライブパターンなどが含まれます。

2. Redis の利点は何ですか?

回答: Redis の利点には、高いパフォーマンス、スケーラビリティ、データの永続性、豊富なデータ型、トランザクションと Lua スクリプトのサポート、および柔軟な構成オプションが含まれます。さらに、Redis は Python、Java、Ruby などの複数のプログラミング言語をサポートしているため、アプリケーションと簡単に統合できます。

3. Redis はデータの永続性をどのように実装しますか?

回答:
Redis は、データをディスク上のファイルに保存することでデータの永続性を実現できます。
Redis は、RDB や AOF などのさまざまな永続化メソッドを提供します。
RDB は Redis データをディスク上のスナップショットファイルに保存しますが、AOF は Redis の書き込み操作を記録してディスク上のログファイルに保存します。サーバーの起動時に、Redis はスナップショットファイルまたはログファイルからデータを復元できます。

4. Redis は同時アクセスをどのように処理しますか?

回答: Redis はシングルスレッドですが、非同期 I/O と多重化を使用して複数のクライアント要求を同時に処理します。さらに、Redis は同時アクセスの問題を回避するためにオプティミスティックロックメカニズムを使用します。2 つのクライアントが同時に同じキーの値を変更しようとすると、Redis は操作の種類 (SET、INCRBY など) に応じて異なる操作を実行します。

5. Redis のデータ構造は何ですか?

回答: Redis は、文字列、リスト、ハッシュテーブル、セット、ソートセットなど、さまざまなデータ構造をサポートしています。文字列は、テキストまたはバイナリデータを保存するために使用される最も単純なデータ構造です。リストは、キュー、スタック、パブリッシュ/サブスクライブパターンなどの実装に使用できる文字列の順序付きリストです。ハッシュテーブルは、連想配列と同様に、キーと値のペアを格納するために使用されます。セットは、交差、和集合、差分を実装するために使用できる順序のない文字列のコレクションです。順序付きセットは文字列の順序付きコレクションであり、各文字列にはスコアが関連付けられており、リーダーボードやカウンターなどの実装に使用できます。

6. Redis のマスター/スレーブレプリケーションとは何ですか?

回答: Redis のマスター/スレーブレプリケーションとは、1 つの Redis サーバーのデータを他の Redis サーバーにコピーして、各サーバーが独立して読み取り操作サービスを提供できるようにすることを指します。マスター/スレーブレプリケーションは次のプロセスに分割できます。

プライマリサーバーの永続化操作: プライマリサーバーは、書き込みコマンドを AOF または RDB ファイルに記録します。
スレーブサーバーの同期操作: スレーブサーバーはマスターサーバーとの接続を確立し、マスターサーバーの書き込みコマンドを受信して実行します。
サーバーからのオンラインレプリケーション: マスターサーバーはスレーブサーバーから切断され、スレーブサーバーは読み取り操作リクエストを受け入れることができる独立した Redis データベースになります。

7. Redis の有効期限戦略は何ですか?

回答: Redis は有効期限を通じて有効期限戦略を実装します。主な有効期限戦略は 2 つあります。

定期的な削除: Redis はデータセット全体を定期的に走査し、期限切れのキーと値のペアを削除します。
遅延削除: Redis はキーと値のペアの読み取りおよび書き込みを行うときに、有効期限をチェックし、有効期限が切れた場合はすぐに削除します。

8. Redis と Memcached の違いは何ですか?

回答: Redis と Memcached はどちらもメモリベースのキャッシュシステムですが、Redis は Memcached よりも多くのデータ構造 (ハッシュ、リスト、セット、順序付きセットなど) をサポートしており、データをディスクに永続化することもできます。さらに、Redis は、パブリッシュサブスクリプション、Lua スクリプト、トランザクションなど、より多くの機能も提供します。

9. Redis のアーキテクチャ設計は何ですか?

回答: Redis のアーキテクチャ設計はシングルスレッドアプローチを採用しています。つまり、すべてのリクエストが 1 つのスレッドで処理されます。この設計により、マルチスレッドの競合問題を回避し、パフォーマンスと安定性を向上させることができます。同時に、Redis は複数のクライアントによる同時アクセスもサポートします。

10. Redis はどのような高度な機能をサポートしていますか?

回答: Redis は、パブリッシュとサブスクライブ、Lua スクリプト、トランザクションなど、さまざまな高度な機能をサポートしています。パブリッシュ/サブスクライブは、複数のクライアントにメッセージをブロードキャストするために使用されるメッセージングパターンです。Lua スクリプトは、Redis で実行できる埋め込みスクリプト言語です。トランザクションは、アトミック性が保証できるコマンドの集合です。

11. Redis にはどのような種類のデータ削除戦略がありますか?

noeviction: メモリ制限に達し、クライアントがより多くのメモリを使用するコマンドを実行しようとした場合にエラーを返します (ほとんどの
書き込みコマンド、ただし DEL といくつかの例外)
allkeys-lru: 新しく追加されたデータ用のスペースを確保するために、最も使用されていないキー (LRU) を再利用しようとします。
volatile-lru: 最も使用されていないキー (LRU) の再利用を試みますが、新しく追加されたデータ
用の余地が残るように、期限切れのコレクション内のキーのみを対象とします。
allkeys-random: ランダムキーをリサイクルして、新しく追加されたデータ用のスペースを確保します。
volatile-random: ランダムキーをリサイクルして、新しく追加されたデータ用のスペースを確保しますが、有効期限が切れたコレクション内のキーのみを対象とします。
volatile-ttl: 期限切れのコレクション内のキーをリサイクルし、新しく追加されたデータに保存するスペースを確保できるように、有効期間 (TTL) の短いキーのリサイクルを優先します。

12. Redis クラスターソリューションでは何を行う必要がありますか? 計画は何ですか?

twemproxy は、一般的な概念はプロキシメソッドに似ており、使用方法は通常の redis と変わりません
。その配下に複数の redis インスタンスを設定した後、使用する場合は、redis が必要な場所で twemproxy に接続します。接続すると、
プロキシとしてリクエストを受信し、一貫性のあるハッシュアルゴリズムを使用してリクエストを特定の Redis に転送し、結果を
twemproxy に返します。使いやすい (redis に比べて、接続ポートを変更するだけで済みます)、古いプロジェクトの拡張の最初の選択肢です。問題: twemproxy 自身の単一ポートインスタンスの圧力により、一貫したハッシュを使用した後、
redis ノードの数が変化して計算値が変化すると、
データを新しいノードに自動的に移動できなくなります。
現在最も使用されているクラスターソリューションである Codis は、基本的には twemproxy と同じ効果がありますが、ノードの数が変更されたときに
古いノードデータを新しいハッシュノードに復元できることをサポートしています。
rediscluster3.0に付属するクラスタは、分散アルゴリズムが一貫性のあるハッシュではなく、ハッシュスロットの概念を採用している点と、スレーブノードの設定を
サポートするノードをサポートしている点が特徴です。詳細については公式ドキュメントを参照してください。
ビジネスコードレイヤーで実装され、無関係な複数の Redis インスタンスを起動し、コードレイヤーでキーのハッシュ計算を実行し、
対応する Redis インスタンスに移動してデータを操作します。この方法にはハッシュレイヤーコードに対する要件が比較的高く、
ノード障害後の代替アルゴリズムソリューション、データショック後の自動スクリプト回復、インスタンスの監視などが考慮されます。

13. キャッシュの侵入、キャッシュの破壊、キャッシュなだれとその解決策について話しますか?

キャッシュペネトレーションの
問題: 多数の同時クエリがキャッシュとデータベースに存在しない KEY に存在し、キャッシュとデータベースに同時に負荷をかけます。
理由: 一般に、キャッシュの侵入には 2 つの可能性があります。1 つはビジネスデータが誤って削除され、その結果キャッシュとデータベースにデータが存在しなくなることです。悪意のある DDOS 攻撃。
分析: なぜ何度も透過的に送信されるのでしょうか? 存在しない場合は常に空となるため、キャッシュ上でKEYの有無とnull値のクエリを区別できるように注意する必要があります。
解決策: null 値を使用して KEY をキャッシュします。これにより、初めてキーが存在しない場合はロードされて記録され、次回保存されます (非同期スレッドは、キャッシュされたデータを維持し、定期的に更新をトリガーする責任があります)条件に応じて)、更新がトリガーされないようにします。
キャッシュの故障の
問題: KEY が無効になると、この KEY にアクセスする大量のリクエストが同時に発生します。
分析: これは実際には浸透と非常に似ており、非常に偶然です。
解決策: KEY の更新操作により、グローバルミューテックスが追加されます。これは完全にキャッシュに基づいており、非同期読み込みを遅らせる戦略を使用してトラフィックの圧力がデータベースに伝達され、データベースに過剰な圧力がかかったり、ダウンタイムが発生したりすることもあります。
キャッシュなだれ
問題：ある瞬間に大規模なキャッシュ障害が発生すると、大量のリクエストがデータを取得できなくなるため、KEY. ブルームフィルタやRoaingBitmapでKEYが存在するかどうかを判定し、ブルームフィルタでデータが見つからなかった場合はデータベースでチェックされません。リクエストを処理する前に悪意のあるリクエストのチェックを追加します。悪意のある攻撃が検出された場合、サービスは拒否されます。これは完全にキャッシュに基づいており、遅延非同期読み込み戦略 (非同期スレッドはキャッシュされたデータを維持し、定期的または条件に従って更新をトリガーする責任があります) を使用するため、更新はトリガーされません。
理由: 一般的に、キャッシュ雪崩には 2 つの可能性があります: 大量のデータが同時に障害を起こす: たとえば、強力なビジネス関係を持つデータには同時障害が必要です。 Redis のダウンタイム分析: 一般的に、更新戦略またはデータホットスポットが原因です
。、キャッシュサービスのダウンタイムなどの理由により、キャッシュされたデータが同時に大規模に利用できなくなったり、すべてが更新される可能性があります。したがって、更新戦略は時間内に適切である必要があり、データは均等に共有され、複数のキャッシュサーバーの可用性が高くなければなりません。
解決策: 更新戦略は、時間的には比較的平均的である必要があります。データを同時に期限切れにする必要がある場合は、このデータバッチにいくつかのランダムな値を追加して、このデータバッチが同時に期限切れにならないようにして、データベースへの負担を軽減できます。使用されるホットデータは、可能な限り別のマシンに分散する必要があります。複数のマシンがマスター/スレーブレプリケーションまたは複数のコピーとして機能し、高可用性を実現します。マスター/スレーブ展開を適切に行うと、マスターノードがハングアップした場合でも、すぐにスレーブノードを上位で使用できるようになります。ヒューズ電流制限機構を実現し、システムの負荷容量を制御します。非コア機能を持つ企業の要求は拒否され、コア機能を持つ企業のみがデータベースにアクセスしてデータを取得することが許可されます。サービス価格の引き下げ: デフォルトの戻り値、または単純なプロンプトメッセージを提供します。

14. Redis データ構造圧縮リストとジャンプテーブルの違い

圧縮リスト (ziplist) は本質的にバイト配列です。メモリを節約するために Redis によって設計された線形データ構造です。複数の要素を含めることができ、各要素はバイト配列または整数にすることができます。
スキップリスト (skiplist) は順序付けされたデータ構造であり、各ノード内で他のノードへの複数のポインタを維持することによってノードに迅速にアクセスするという目的を達成します。ジャンプテーブルは、平均 O(logN) および最悪 O(N) の複雑さによるノードルックアップをサポートし、順次操作を通じてノードをバッチで処理することもできます。

15. 文字列型の値が格納できる最大容量はどれくらいですか?

答え: 512M

16. Redis の一般的なデータ構造について教えてください。それぞれの使用シナリオは?

文字列
の概要: 文字列データ構造は、単純なキーと値のタイプです。
利用シナリオ：一般的に、ユーザーの訪問数や人気記事のいいね数やリポスト数など、カウントが必要なシナリオで使用されます。
リスト
の概要: リストはリンクされたリストです。
使用シナリオ: パブリッシュおよびサブスクライブまたはメッセージキュー、低速クエリ。
ハッシュの
概要: ハッシュは JDK1.8 より前の HashMap に似ており、内部実装も同様です (配列 + リンクリスト)。
使用シナリオ: システム内のオブジェクトデータの保存。
セットの
紹介: セットは Java の HashSet に似ています。Redis のセットタイプは順序のないコレクションであり、コレクション内の要素には順序がありません。
Set は、データのリストを保存する必要があり、重複したデータを望まない場合に適した選択肢です。set は、メンバーがセットコレクションに含まれているかどうかを判断するための重要なインターフェイスを提供しますが、リストでは提供できません。
積、和、差の演算を集合に基づいて簡単に実現
シナリオ: 格納する必要のあるデータを繰り返すことができず、複数のデータソースの積と和を取得する必要がある
ソートセット
の概要: ソートセットはセットと比較して重みパラメータスコアを追加するため、セット内の要素をスコアに従って順序で配置することができ、スコアの範囲を通じて要素のリストを取得することもできます。これは、Java の HashMap と TreeSet の組み合わせに似ています。
使用シナリオ: 特定の重みに従ってデータを並べ替える必要があるシナリオ。例えば、ライブブロードキャストシステムにおいて、リアルタイムランキング情報には、ライブブロードキャストルームのオンラインユーザーのリスト、各種ギフトランキング、集中メッセージ（メッセージ次元によるメッセージランキングとして理解できる）およびその他の情報が含まれる。
ビットマップ
の概要: ビットマップは連続 2 進数 (0 と 1) を格納します。ビットマップを通じて、要素に対応する値または状態を表すのに必要なビットは 1 つだけであり、キーは対応する要素自体です。8 ビットで 1 バイトを形成できることがわかっているため、ビットマップ自体によりストレージスペースが大幅に節約されます。。
使用シナリオ: ステータス情報 (サインインするかどうか、ログインするかどうかなど) を保存し、この情報をさらに分析する必要があるシナリオに適しています。たとえば、ユーザーのチェックインステータス、アクティブユーザーステータス、ユーザーの行動統計 (特定のビデオが好きかどうかなど)。

17. Redis の一般的なパフォーマンスの問題と解決策:

マスターのメモリスナップショットを書き込まないことをお勧めします。マスターがメモリスナップショットを書き込む場合、save コマンドは rdbSave 関数をスケジュールし、メインスレッドの作業をブロックします。スナップショットが比較的大きい場合、パフォーマンスへの影響が大きくなります。非常に大規模なため、サービスが断続的に停止されます
データがより重要な場合、スレーブは AOF バックアップデータをオンにし、ポリシーは 1 秒に 1 回同期するように設定されます。
マスターとスレーブのレプリケーションの速度と接続の安定性を考慮すると、マスターとスレーブが同じ LAN 内にあることが最適です。
高圧下ではメインライブラリにスレーブライブラリを追加しないようにしてください。
マスター/スレーブレプリケーションにはグラフ構造を使用しないでください。一方向リンクリスト構造、つまりマスター <- スレーブ 1 <- スレーブ 2 <- スレーブ 3... を使用する方が安定しています。この構造は、単一点の問題を解決するのに便利です。障害問題を解決し、スレーブからマスターへの置き換えを実現します。マスターが電話を切った場合は、すぐにスレーブ 1 をマスターとして有効にすることができ、他のものは変更されません。

18. Redis がすべてのデータをメモリに配置する必要があるのはなぜですか?

回答: 最速の読み取りおよび書き込み速度を実現するために、Redis はすべてのデータをメモリに読み取り、データをディスクに非同期で書き込みます。
つまり、redis は高速かつデータの永続性という特徴を持っています。データがメモリに配置されていない場合、ディスク I/O 速度が Redis のパフォーマンスに重大な影響を与えます。メモリがどんどん安くなっている現在、redis の人気はますます高まるでしょう。使用される最大メモリが設定されている場合、既存のデータレコードの数がメモリ制限に達すると、新しい値を挿入できなくなります。

19. Redis の同期メカニズムを理解していますか?

回答: Redis はマスター/スレーブ同期とスレーブ/スレーブ同期を使用できます。
最初の同期中に、マスターノードは bgsave を実行し、同時に後続の変更操作をメモリバッファーに記録します。完了後、rdb ファイルはレプリケーションノードに完全に同期されます。レプリケーションノードがそれを受け入れると、 rdbイメージがメモリにロードされます。
ロードが完了したら、変更された操作レコードをコピーノードに同期して再生し、同期プロセスを完了するようにマスターノードに通知します。

20. パイプラインの利点は何ですか?なぜパイプラインを使用するのですか?

回答: パイプラインによって実行される命令間に因果関係がない場合、複数の IO ラウンドトリップにかかる時間は 1 回に短縮できます。圧力テストに redis-benchmark を使用すると、redis の QPS ピーク値に影響を与える重要な要素がパイプラインバッチ命令の数であることがわかります。

21. Redis クラスターを使用したことがありますか? クラスターの原理は何ですか?

Redis Sentinal は高可用性を重視しており、マスターがダウンすると、自動的にスレーブをマスターに昇格させてサービスを提供し続けます。
Redis Cluster はスケーラビリティに重点を置き、単一の Redis メモリが不十分な場合にシャードストレージとして Cluster を使用します。

22. Redis でサポートされている Java クライアントは何ですか? 公式で推奨されているのはどれですか？

回答: Redisson、Jedis、レタスなどは Redisson を使用することが公式に推奨されています。

23. ジェダイとレディソンの長所と短所は何ですか?

回答: Jedis は Java で実装された Redis のクライアントであり、その API は Redis コマンドの包括的なサポートを提供します。Redisson は
分散型でスケーラブルな Java データ構造を実装します。Jedis と比較して、その機能は単純であり、文字列はサポートされていません。操作はサポートされていません。ソート、トランザクション、パイプライン、パーティションなどの Redis 機能をサポートします。
Redisson の目的は、Redis に対するユーザーの懸念の分離を促進し、ユーザーがビジネスロジックの処理により集中できるようにすることです。

24. Redis でパスワードを設定し、パスワードを確認するにはどうすればよいですか?

设置密码：config set requirepass 123456
授权密码：auth 123456

25. Redis ハッシュスロットの概念について教えてください。

回答: Redis クラスターは一貫性のあるハッシュを使用しませんが、ハッシュスロットの概念を導入しています。Redis クラスターには 16384 個のハッシュスロットがあり、ノードはハッシュスロットの一部を担当します。

26. Redis クラスターのマスター/スレーブレプリケーションモデルとは何ですか?

回答: 一部のノードに障害が発生したり、ほとんどのノードが通信できなくなった場合でもクラスターを引き続き使用できるようにするために、クラスターはマスター/スレーブレプリケーションモデルを使用し、各ノードには N-1 個のレプリカが存在します。

27. Redis クラスターで書き込み操作は失われますか? なぜ？

回答: Redis はデータの強力な一貫性を保証できません。つまり、実際には、特定の条件下でクラスターが書き込み操作を失う可能性があります。

28. Redis クラスターはどのようにレプリケートされますか?

回答: 非同期レプリケーション

29. Redis クラスター内のノードの最大数はどれくらいですか?

答え: 16384。

30. Redis クラスターはどのようにデータベースを選択しますか?

回答: Redis クラスターは現在データベースを選択できず、デフォルトは 0 データベースです。

31. Redis トランザクションに関連するコマンドは何ですか?

答：マルチ、実行、破棄、監視

32. Redis キーの有効期限と永続的な有効性を設定するにはどうすればよいですか?

回答: EXPIRE および PERSIST コマンドです。

33. Redis 分散ロックを使用したことがありますか? それはどのようなものですか?

回答: setnx を使用して最初にロックを取得し、次に、expired を使用してロックに有効期限を追加し、ロックの解放忘れを防ぎます。setnx の後、有効期限が切れる前にプロセスが予期せずクラッシュした場合、またはメンテナンスのために再起動する必要がある場合、set コマンドには非常に複雑なパラメータがあり、setnx とexpir を 1 つのコマンドに結合して同時に使用できます。

34. Redis に最適なシナリオは何ですか?

Redis を使用するために最も一般的に使用されるシナリオの 1 つは、セッションキャッシュです。
Redis を使用して他のストレージ (Memcached など) 上でセッションをキャッシュする利点は、Redis が永続性を提供することです。厳密に一貫性のないキャッシュを維持する場合、ユーザーのショッピングカート情報がすべて失われたら、ほとんどの人は不満を抱くでしょう。幸いなことに、Redis は長年にわたって改良されてきたため、セッションキャッシュに Redis を適切に使用する方法に関するドキュメントを簡単に見つけることができます。有名なビジネスプラットフォームである Magento でさえ、Redis 用のプラグインを提供しています。
フルページキャッシュ (FPC)
基本的なセッショントークンに加えて、Redis は非常にシンプルな FPC プラットフォームも提供します。一貫性の問題に戻りますが、Redis インスタンスが再起動されても、ユーザーはディスクの永続化によってページの読み込み速度が低下することはありません。これは、PHP のローカル FPC と同様に、大きな改善です。再び Magento を例に挙げると、Magento は Redis をフルページキャッシュバックエンドとして使用するためのプラグインを提供します。さらに、WordPress ユーザー向けに、Pantheon には非常に優れたプラグイン wp-redis があり、アクセスしたページをできるだけ早く読み込むのに役立ちます。
キュー
メモリストレージエンジンの分野における Reid の利点の 1 つは、Redis がリストおよびセット操作を提供することです。これにより、Redis は使用するのに適したメッセージキュープラットフォームになります。Redis がキューとして使用する操作は、リストに対するローカルプログラミング言語 (Python など) のプッシュ/ポップ操作に似ています。Google で「Redis キュー」を検索すると、Redis を使用してさまざまなキューのニーズに対応する非常に優れたバックエンドツールを作成することを目的としたオープンソースプロジェクトがすぐに大量に見つかります。たとえば、Celery には Redis をブローカーとして使用するバックグラウンドがあり、ここから確認できます。
リーダーボード/カウンター
Redis は、メモリ内の数値を増減する優れた仕事をします。Set と Sorted Set を使用すると、これらの操作の実行が非常に簡単になります。Redis はこれら 2 つのデータ構造を提供するだけです。したがって、ソートされたセットから上位 10 人のユーザーを取得したいとします。これを「user_scores」と呼びます。次のように実行するだけです。もちろん、これはユーザーのスコアに基づいて実行していることを前提としています。増分ソート。ユーザーとユーザーのスコアを返したい場合は、次のように実行する必要があります: ZRANGE user_scores 0 10 WITHSCORES Agora Games は良い例で、Ruby で実装されており、そのリーダーボードは Redis を使用してデータを保存しています。ここで見つけることができます。。
パブリッシュ/サブスクライブ
最後に (もちろん重要ですが) Redis のパブリッシュ/サブスクライブ機能です。パブリッシュ/サブスクライブには実際に多くの使用例があります。人々がこれをソーシャルネットワーキング接続で使用したり、pub/sub ベースのスクリプトのトリガーとして使用したり、チャットシステムを構築するために Redis の pub/sub 機能を使用したりしているのを見てきました。