記事は長すぎるため、最初に保存してゆっくり読むことをお勧めします。
Redis (Remote Dictionary Server) は、C 言語で書かれたオープンソース (BSD ライセンス) の高性能非リレーショナル (NoSQL) キー/値データベースです。
#Redis は、キーと 5 つの異なるタイプの値の間のマッピングを保存できます。キー タイプは文字列のみであり、サポートされるデータ タイプは の 5 つだけです: 文字列、リスト、セット、ハッシュ テーブル、順序付きセットです。
従来のデータベースとは異なり、Redis データはメモリに保存されるため、読み取りと書き込みの速度が非常に高速です。そのため、Redis はキャッシュ方向で広く使用されており、100,000 回を超える読み取りと書き込みを処理できます。これは、既知の中で最も高速に実行される Key-Value DB です。さらに、Redis は分散ロックによく使用されます。さらに、Redis はトランザクション、永続性、LUA スクリプト、LRU 駆動イベント、およびさまざまなクラスター ソリューションをサポートします。
今日は、職場復帰後の面接に備えるための Redis 面接の質問 についてお話します。
1. 概要
1. Redis の長所と短所は何ですか
利点
読み取りおよび書き込みパフォーマンス 優れており、Redis は 110,000 回/秒の速度で読み取り、81,000 回/秒の速度で書き込みます。
データの永続性をサポートし、AOF と RDB の 2 つの永続化メソッドをサポートします。
トランザクションをサポートします。Redis のすべての操作はアトミックです。同時に、Redis は複数の操作をマージした後のアトミック実行もサポートします。
豊富なデータ構造。文字列型の値をサポートするだけでなく、ハッシュ、セット、zset、リスト、その他のデータ構造もサポートします。
マスター/スレーブ レプリケーションをサポートし、ホストはデータをスレーブに自動的に同期し、読み取りと書き込みを分離できます。
欠点
データベース容量は物理メモリによって制限されており、大量のデータの高パフォーマンスな読み取りおよび書き込みには使用できないため、Redis に適したシナリオは次のとおりです。主に少量のデータに限定され、高性能の演算と計算が可能です。
Redis には自動フォールト トレランス機能と回復機能がありません。ホスト マシンとスレーブ マシンのダウンタイムにより、一部のフロントエンドの読み取りおよび書き込みリクエストが失敗します。マシンが再起動するまで待つか、手動で切り替える必要があります。回復するフロントエンド IP。
ホスト マシンがダウンしました。マシンがダウンする前に、一部のデータをスレーブ マシンに同期できませんでした。IP を切り替えた後、データの不整合が生じ、システムの可用性が低下します。
Redis はオンライン拡張に対応しにくく、クラスタ容量が上限に達するとオンライン拡張が非常に複雑になります。この問題を回避するために、運用および保守担当者は、システムがオンラインになったときに十分なスペースを確保する必要がありますが、これによりリソースが大幅に浪費されます。
2. Redis を使用する理由/キャッシュを使用する理由
この問題を主に「高パフォーマンス」と「高同時実行性」の 2 つの点から考察します。
高パフォーマンス:
ユーザーがデータベース内の一部のデータに初めてアクセスする場合。このプロセスはハードディスクから読み取られるため、時間がかかります。ユーザーがアクセスしたデータをキャッシュに保存し、次回アクセスしたときにキャッシュから直接データを取得できるようにします。 オペレーションキャッシュはメモリを直接操作するため、かなり高速です。データベース内の対応するデータが変更された場合は、キャッシュ内の対応するデータを同期的に変更するだけです。
高い同時実行性:
直接操作キャッシュが耐えられるリクエストは、への直接アクセスよりもはるかに多くなります。したがって、データベース内の一部のデータをキャッシュに転送して、ユーザーのリクエストの一部がデータベースを経由せずに直接キャッシュに送られるようにすることを検討できます。
3. キャッシュにマップ/グアバではなく Redis を使用する理由
キャッシュはローカル キャッシュと分散キャッシュに分かれています。 Javaを例に挙げると、ローカルキャッシュは組み込みマップやguavaを利用して実装されており、軽量かつ高速であることが最大の特徴であり、ライフサイクルはjvmの破棄で終了し、複数のインスタンスの場合はそれぞれのインスタンス 各キャッシュを保存する必要がありますが、キャッシュは一貫していません。
redis または memcached の使用は分散キャッシュと呼ばれ、複数のインスタンスの場合、各インスタンスはデータのキャッシュを共有し、キャッシュは一貫しています。欠点は、redis または memcached サービスの可用性を高く保つ必要があり、プログラム アーキテクチャ全体が比較的複雑であることです。
4. Redis はなぜ速いのですか?
1) 完全にメモリに基づいているため、ほとんどのリクエストは純粋なメモリ操作であり、非常に高速です。データは HashMap と同様にメモリに保存されます。HashMap の利点は、検索と操作の時間計算量が O(1);
2) データ構造が単純で、データ操作も簡単であることです。 Redis のデータ構造は特別に設計されています;
3) 単一のスレッドを使用すると、不必要なコンテキストの切り替えや競合状態が回避され、複数のプロセスまたはスレッド間で切り替えて CPU を消費する必要がなく、さまざまなロックの問題を考慮する必要もありません。ロックまたはロックの解放。操作、デッドロックの可能性によるパフォーマンスの消費はありません;
4) マルチチャネル I/O 多重化モデル、ノンブロッキング IO を使用します;
5 基礎となるモデルのモデルが異なる 基礎となる実装方法とクライアントと通信するためのアプリケーション プロトコルが異なる 一般的なシステムがシステム関数を呼び出すと、移動とリクエストに一定の時間が無駄になるため、Redis は独自の VM メカニズムを直接構築します;
2. データ型
5. Redis にはどのようなデータ型がありますか?
Redis には主に String、List、 Set、Zset、および Hash は、ほとんどのユーザーのニーズを満たすことができます。使用要件の一部
6. Redis アプリケーション シナリオ
#概要 1
Counter: String に対してインクリメントおよびデクリメント操作を実行して、カウンター機能を実現できます。インメモリ データベースである Redis は、非常に高い読み取りおよび書き込みパフォーマンスを備えており、頻繁な読み取りおよび書き込みの回数を保存するのに非常に適しています。
キャッシュ: ホットスポット データをメモリに配置し、キャッシュ ヒット率を確保するために最大メモリ使用量と排除戦略を設定します。
セッション キャッシュ: Redis を使用すると、複数のアプリケーション サーバーのセッション情報を均一に保存できます。アプリケーション サーバーがユーザーのセッション情報を保存しなくなると、アプリケーション サーバーは状態を持たなくなり、ユーザーは任意のアプリケーション サーバーをリクエストできるようになり、高可用性とスケーラビリティを実現しやすくなります。
フル ページ キャッシュ (FPC): 基本的なセッション トークンに加えて、Redis は非常にシンプルな FPC プラットフォームも提供します。 Magento を例に挙げると、Magento は Redis をフルページ キャッシュ バックエンドとして使用するためのプラグインを提供します。さらに、WordPress ユーザー向けに、Pantheon には非常に優れたプラグイン wp-redis があり、閲覧したページをできるだけ早く読み込むのに役立ちます。
ルックアップ テーブル: たとえば、DNS レコードは、Redis を使用したストレージに非常に適しています。ルックアップ テーブルはキャッシュに似ており、Redis の高速ルックアップ機能も利用します。ただし、キャッシュは信頼できるデータ ソースとして機能しないため、ルックアップ テーブルの内容は無効にできませんが、キャッシュの内容は無効にできます。
メッセージ キュー (パブリッシュ/サブスクライブ機能): List は、lpush および rpop を介してメッセージを読み書きできる双方向リンク リストです。ただし、Kafka や RabbitMQ などのメッセージング ミドルウェアを使用することをお勧めします。
分散ロックの実装: 分散シナリオでは、スタンドアロン環境のロックを使用して複数のノード上のプロセスを同期することはできません。 Redis に付属の SETNX コマンドを使用して分散ロックを実装できます。また、公式に提供されている RedLock 分散ロック実装を使用することもできます。
その他: Set は交差や和集合などの演算を実装することで、共通の友人などの機能を実現します。 ZSet は順序付けされた操作を実装して、ランキングなどの機能を実現できます。
要約 2
他のキャッシュと比較すると、Redis には複数のデータ型をサポートしているという非常に大きな利点があります。 データ型説明文字列、最も単純な k-v ストレージ ハッシュハッシュ形式、値はフィールドと値であり、ID 詳細などのシナリオに適しています。 list は単純なリスト、順次リスト、最初または最後の位置でのデータの挿入をサポート、順序なしリスト、高速な検索速度、交差、和集合、および差分の処理に適しています。ソートされたセット順序付きセット実際には、上記のデータから、タイプの特性に基づいて、基本的に適切なアプリケーション シナリオを考えることができます。 string—memcached ストレージ構造、SMS 検証コード、構成情報などに似た、最も単純な k-v ストレージに適しており、このタイプを使用して保存します。hash - 通常、キーは ID または一意の識別子であり、値は詳細に対応します。製品詳細、個人情報詳細、ニュース詳細など。
list——リストは順序付けされているため、順序付けされた比較的固定されたデータを格納するのに適しています。県市表、辞書表など。リストは順序付けされているため、最新の***、メッセージキューなど、書き込み時間に従ってソートするのに適しています。
set——これは、Weibo 上でその人がどのような友達を持っているかなど、ID リスト モデルとして単純に理解できます。set の最も優れている点は、2 つの間の共通部分を提供できることです。セット、和集合、差分演算。例: 2 人の共通の友人を見つけるなど。
Sorted Set—— は、セットの拡張バージョンであり、スコア値に従って自動的に並べ替えるスコア パラメーターを追加しています。上位 10 位など、挿入時間順にソートされていないデータに適しています。
上で述べたように、Redis はリレーショナル データベースほど複雑なデータ構造ではありませんが、一般的なキャッシュ データ構造以上のものを含む多くのシナリオにも適しています。それぞれのデータ構造に適したビジネスシナリオを理解することで、開発効率の向上だけでなく、Redisのパフォーマンスを有効に活用することもできます。 3. 永続性7. Redis の永続性とは何ですか?
永続化とは、サービスがダウンした場合にメモリ データが失われるのを防ぐために、メモリ データをディスクに書き込むことです。8. Redis の永続化メカニズムとは何ですか?それぞれの長所と短所は何ですか?
Redis は、RDB (デフォルト) と AOF メカニズムの 2 つの永続化メカニズムを提供します。
RDB: は、Redis DataBase
RDB の略称スナップショットです。これは Redis のデフォルトの永続化メソッドです。メモリデータは一定期間ごとにスナップショット形式でハードディスクに保存され、対応するデータファイルがdump.rdbとして生成されます。スナップショットの期間は、構成ファイルの save パラメーターによって定義されます。
利点:
1. ファイル dump.rdb が 1 つだけあるため、永続化に便利です。
2. 耐災害性が高く、ファイルを安全なディスクに保存できます。
3. パフォーマンスを最大化するには、子プロセスをフォークして書き込み操作を完了し、メイン プロセスがコマンドの処理を継続できるようにして、IO を最大化します。永続化には別のサブプロセスを使用し、メイン プロセスは IO 操作を実行せず、redis
4 の高いパフォーマンスを確保します。データ セットが大きい場合、起動効率は AOF よりも高くなります。
欠点:
1. データのセキュリティが低い。 RDB は一定の間隔で永続化されますが、永続化の間に redis に障害が発生するとデータ損失が発生します。したがって、この方法は、データ要件が厳密ではない場合に適しています)
2. AOF (追加専用ファイル) 永続化方法: すべてのコマンド ライン レコードが redis コマンドの形式で完全に永続的に保存されることを指します。 request プロトコル ) は aof ファイルとして保存されます。
AOF: 永続性
AOF 永続性 (つまり、ファイル追加のみの永続性) は、Redis によって実行された各書き込みコマンドを別のログ ファイルに記録します。Redis の再起動時に、データが記録されます。永続的なログ ファイルが復元されます。
両方の方法を同時に有効にすると、データ回復 Redis は AOF 回復を優先します。
利点:
1. データ セキュリティ、永続性は、コマンド操作のたびに、appendfsync 属性を使用して設定できます。 aof ファイルに一度記録するだけです。
2. 追加モードでファイルを書き込む サーバーが途中でダウンした場合でも、redis-check-aof ツールを使用してデータの一貫性の問題を解決できます。
3. AOF メカニズムの書き換えモード。 AOF ファイルが書き換えられる前に (ファイルが大きすぎる場合、コマンドはマージされて書き換えられます)、一部のコマンド (誤ってフラッシュオールなど) を削除する可能性があります。)
欠点:
1. AOF ファイルは RDB ファイルに比べてサイズが大きく、回復速度が遅くなります。
2. データセットが大きい場合、rdbよりも起動効率が悪くなります。
メリットとデメリットは何ですか?
AOF ファイルは RDB よりも頻繁に更新されるため、データの復元には最初に AOF が使用されます。
AOF は RDB より安全で大容量です
RDB のパフォーマンスは AOF より優れています
両方が構成されている場合は、AOF が最初にロードされます
9 、適切な永続化メソッドの選択方法
一般に、PostgreSQL と同等のデータ セキュリティを実現したい場合は、両方の永続化機能を同時に使用する必要があります。この場合、Redis が再起動されると、AOF ファイルが最初にロードされて元のデータが復元されます。これは、通常の状況では、AOF ファイルによって保存されたデータ セットの方が、RDB ファイルによって保存されたデータ セットよりも完全であるためです。
データを非常に重視していても、数分以内のデータ損失は許容できる場合は、RDB 永続性を使用するだけで済みます。
多くのユーザーは AOF 永続性のみを使用しますが、RDB スナップショットを定期的に生成することはデータベースのバックアップに非常に便利であり、RDB データ セットのリカバリは AOF リカバリよりも高速であるため、この方法はお勧めできません。 RDB を使用すると、AOF プログラムのバグを回避することもできます。
サーバーの実行中にのみデータを存在させたい場合は、永続化メソッドを使用することもできません。
10. Redis の永続データとキャッシュを拡張するにはどうすればよいですか?
Redis をキャッシュとして使用する場合は、コンシステント ハッシュを使用して動的な拡張と縮小を実現します。
Redis を永続ストレージとして使用する場合は、固定のキーとノードのマッピング関係を使用する必要があり、ノードの数は一度決定すると変更できません。それ以外の場合 (つまり、Redis ノードを動的に変更する必要がある場合)、実行時にデータのバランスを再調整できるシステムを使用する必要があります。現在、これを実行できるのは Redis クラスターのみです。
4. メモリ関連
14. MySQL には 2,000 万のデータがありますが、redis には 20 万のデータしか保存されません。redis 内のデータがホット データであることを確認する方法?
Redis メモリ データ セットのサイズが特定のサイズに増加すると、データ削除戦略が実装されます。
15. Redis のメモリ削除戦略は何ですか?
Redis のメモリ削減戦略とは、Redis のキャッシュ用メモリが不十分な場合に、新たに書き込む必要があり、追加のスペース アプリケーションが必要なデータを処理する方法を指します。
グローバル キー スペースの選択的削除
noeviction: メモリが新しく書き込まれたデータを収容するのに十分でない場合、新しい書き込み操作はレポートを実行します。エラー。
allkeys-lru: 新しく書き込まれたデータを格納するにはメモリが不足している場合、キー スペースで、最も最近使用されていないキーを削除します。 (これが最も一般的に使用されます)
allkeys-random: メモリが新しく書き込まれたデータを収容するのに不十分な場合、キーはキー空間からランダムに削除されます。
有効期限付きのキースペースの選択的削除
volatile-lru: メモリが新しく書き込まれたデータを収容するのに十分でない場合、有効期限が設定されたキースペースで、最も最近使用されていないキーを削除します。
volatile-random: メモリが新しく書き込まれたデータを収容するのに不十分な場合、キーは有効期限が設定されてキー空間からランダムに削除されます。
volatile-ttl: メモリが新しく書き込まれたデータを収容するのに不十分な場合、有効期限が設定されたキー空間では、有効期限が早いキーが最初に削除されます。
概要
Redis のメモリ削除戦略の選択は、期限切れのキーの処理には影響しません。メモリ削除ポリシーは、メモリが不十分な場合に追加の領域を必要とするデータを処理するために使用され、有効期限ポリシーは、期限切れのキャッシュ データを処理するために使用されます。
16. Redis は主にどのような物理リソースを消費しますか? ＃＃＃＃＃＃＃＃＃メモリ。
17. Redis のメモリが不足するとどうなりますか?
設定された上限に達すると、Redis 書き込みコマンドはエラー メッセージを返します (ただし、読み取りコマンドは正常に返されます)。または、メモリ削除メカニズムを構成すると、Redis がフラッシュします。メモリの上限に達すると古いコンテンツになります。
18. Redis はどのようにメモリを最適化しますか?
通常、多数の小さな Key-Value をよりコンパクトな方法でまとめて保存できるため、ハッシュ、リスト、ソート セット、セットなどのコレクション型データを有効に活用できます。 。可能な限りハッシュを使用する ハッシュ テーブル (ハッシュ テーブルに格納される数値が小さいことを意味します) は非常に少量のメモリを使用するため、データ モデルを可能な限りハッシュ テーブルに抽象化する必要があります。たとえば、Web システムにユーザー オブジェクトがある場合、ユーザーの名前、姓、電子メール、パスワードに個別のキーを設定せず、すべてのユーザー情報をハッシュ テーブルに保存します。
5. スレッド モデル19. Redis のスレッド モデル
Redis は、Reactor モードに基づいてネットワーク イベント プロセッサを開発しました。このプロセッサはファイルと呼ばれます。イベントハンドラ。その構造は、複数のソケット、IO マルチプレクサ、ファイル イベント ディスパッチャ、およびイベント プロセッサの 4 つの部分で構成されます。ファイル イベント ディスパッチャー キューの消費はシングル スレッドであるため、Redis はシングル スレッド モデルと呼ばれます。
ファイル イベント プロセッサは、I/O 多重化 (多重化) プロシージャを使用して複数のソケットを同時にリッスンし、ソケット デバイスによって現在実行されているタスクに応じてソケットに異なるイベント処理を関連付けます。 監視対象のソケットが接続応答 (受け入れ)、読み取り (読み取り)、書き込み (書き込み)、閉じる (クローズ) などの操作を実行する準備ができている場合、その操作に対応するファイル イベントが発生します。ファイル イベント ハンドラーは、ソケットに以前に関連付けられていたイベント ハンドラーを呼び出して、これらのイベントを処理します。 ファイル イベント プロセッサはシングル スレッド方式で実行されますが、I/O マルチプレクサを使用して複数のソケットをリッスンすることにより、ファイル イベント プロセッサは高性能のネットワーク通信モデルを実装するだけでなく、同じくシングルスレッド方式で実行される Redis サーバー内の他のモジュールと適切に接続されているため、Redis 内のシングルスレッド設計のシンプルさが維持されます。 6. スレッド モデル19. Redis のスレッド モデル
Redis は、Reactor モードに基づいてネットワーク イベント プロセッサを開発しました。このプロセッサはファイルと呼ばれます。イベントハンドラ。その構造は、複数のソケット、IO マルチプレクサ、ファイル イベント ディスパッチャ、およびイベント プロセッサの 4 つの部分で構成されます。ファイル イベント ディスパッチャー キューの消費はシングル スレッドであるため、Redis はシングル スレッド モデルと呼ばれます。
ファイル イベント プロセッサは、I/O 多重化 (多重化) プロシージャを使用して複数のソケットを同時にリッスンし、ソケット デバイスによって現在実行されているタスクに応じてソケットに異なるイベント処理を関連付けます。 監視対象のソケットが接続応答 (受け入れ)、読み取り (読み取り)、書き込み (書き込み)、閉じる (クローズ) などの操作を実行する準備ができている場合、その操作に対応するファイル イベントが発生します。ファイル イベント ハンドラーは、ソケットに以前に関連付けられていたイベント ハンドラーを呼び出して、これらのイベントを処理します。 ファイル イベント プロセッサはシングル スレッド方式で実行されますが、I/O マルチプレクサを使用して複数のソケットをリッスンすることにより、ファイル イベント プロセッサは高性能のネットワーク通信モデルを実装するだけでなく、同じくシングルスレッド方式で実行される Redis サーバー内の他のモジュールと適切に接続されているため、Redis 内のシングルスレッド設計のシンプルさが維持されます。 7. トランザクション20. トランザクションとは何ですか?
#トランザクションは単一の分離された操作です。トランザクション内のすべてのコマンドはシリアル化され、順番に実行されます。トランザクションの実行中、他のクライアントから送信されたコマンド要求によって中断されることはありません。 トランザクションはアトミックな操作です。トランザクション内のすべてのコマンドが実行されるか、まったく実行されないかのどちらかです。
21. Redis トランザクションの概念Redis トランザクションの本質は、MULTI、EXEC、WATCH などのコマンドの集合です。トランザクションは一度に複数のコマンドの実行をサポートしており、トランザクション内のすべてのコマンドはシリアル化されます。トランザクション実行処理中、キュー内のコマンドは順番に実行され、他のクライアントから送信されたコマンド要求はトランザクション実行コマンドシーケンスに挿入されません。
要約すると、redis トランザクションは、キュー内の一連のコマンドを 1 回限り、順次、排他的に実行します。
22. Redis トランザクションの 3 つの段階
トランザクションの開始 MULTI
コマンド エンキュー
トランザクション実行 EXEC
トランザクション実行中に、サーバーが EXEC、DISCARD、WATCH、MULTI 以外のリクエストを受信した場合、そのリクエストはキューイングインキューに入れられます。
23. Redis トランザクション関連コマンド
Redis トランザクション機能は、MULTI、EXEC、DISCARD、WATCH の 4 つのプリミティブによって実装されます。
Redis は、トランザクション内のすべてのコマンドをシリアル化し、順番に実行します。
1) redis はロールバックをサポートしていません。「トランザクションが失敗したときに Redis はロールバックしませんが、残りのコマンドは実行し続けます」。そのため、Redis の内部はシンプルかつ高速のままです。
2) トランザクション内のコマンドでエラーが発生した場合、すべてのコマンドは実行されません;
.3)If inトランザクションで実行時エラーが発生した場合、正しいコマンドが実行されます。
WATCH コマンドは、Redis トランザクションにチェック アンド セット (CAS) 動作を提供するオプティミスティック ロックです。 1 つ以上のキーを監視できます。キーの 1 つが変更 (または削除) されると、それ以降のトランザクションは実行されず、EXEC コマンドが実行されるまで監視が継続されます。
MULTI コマンドはトランザクションの開始に使用され、常に OK を返します。 MULTI の実行後、クライアントはサーバーに任意の数のコマンドを送信し続けることができます。これらのコマンドはすぐには実行されず、キューに入れられます。EXEC コマンドが呼び出されると、キュー内のすべてのコマンドが実行されます。
EXEC: すべてのトランザクション ブロック内でコマンドを実行します。トランザクションブロック内のすべてのコマンドの戻り値をコマンド実行順に並べて返します。操作が中断されると、空の値 nil が返されます。
DISCARD を呼び出すと、クライアントはトランザクション キューをクリアしてトランザクションの実行を放棄でき、クライアントはトランザクション状態から抜けます。
UNWATCH コマンドは、すべてのキーの監視をキャンセルできます。
24. トランザクション管理 (ACID) の概要
アトミック性: アトミック性とは、トランザクションが分割不可能な作業単位であることを意味します。トランザクションで発生するか、何も発生しません。
一貫性: トランザクションの前後のデータの整合性は一貫している必要があります。
分離: 複数のトランザクションが同時に実行される場合、1 つのトランザクションの実行が他のトランザクションの実行に影響を与えるべきではありません。
耐久性: 耐久性とは、トランザクションがコミットされると、データベース内のデータへの変更が永続的になることを意味します。データベースに障害が発生した場合でも、変更は行われません。影響はありません。
Redis トランザクションは常に ACID で一貫性と分離性を備えています。他の機能はサポートされていません。サーバーが AOF 永続モードで実行されており、appendfsync オプションの値が always である場合も、トランザクションは永続的です。
25. Redis トランザクションは分離をサポートしていますか?
Redis は単一プロセス プログラムであり、トランザクションの実行時にトランザクションが中断されないことが保証されており、トランザクション キュー内のすべてのコマンドが実行されるまでトランザクションを実行できます。したがって、Redis トランザクションは常に分離されます。
26. Redis トランザクションはアトミック性を保証しますか?またロールバックをサポートしますか?
Redis では、単一のコマンドがアトミックに実行されますが、トランザクションはアトミックであることが保証されず、ロールバックはありません。トランザクション内のいずれかのコマンドが実行に失敗した場合でも、残りのコマンドは引き続き実行されます。
27. Redis トランザクションのその他の実装
Lua スクリプトに基づいて、Redis はスクリプト内のコマンドが 1 回ずつ順番に実行されることを保証します。エラー ロールバック、実行中に一部のコマンドが正しく実行されなかった場合、残りのコマンドは完了するまで実行を継続します
中間マーク変数に基づいて、別のマーク変数を使用して、トランザクションが実行されているかどうかを識別します。データ読み出し時 まず、マーク変数を読み込んでトランザクションの実行が完了したかどうかを判定します。ただし、これには追加のコードを実装する必要があり、さらに面倒です。
8. クラスター ソリューション
28. Sentinel モード
Sentinel の概要:
センチネル、中国名はセンチネルです。 Sentinel は Redis クラスター組織において非常に重要なコンポーネントであり、主に次の機能があります:
クラスター監視: Redis マスター プロセスとスレーブ プロセスが適切に動作しているかどうかを監視します。
メッセージ通知: Redis インスタンスに障害が発生した場合、Sentinel はアラーム通知としてメッセージを管理者に送信する責任があります。
フェイルオーバー: マスター ノードがハングすると、自動的にスレーブ ノードに転送されます。
Configuration Center: フェイルオーバーが発生した場合は、新しいマスター アドレスをクライアントに通知します。
Sentinel は、Redis クラスターの高可用性を実現するために使用されます . また、センチネルは分散され、連携して動作するセンチネル クラスターとして実行されます。
フェイルオーバー中に、マスター ノードがダウンしているかどうかを判断するには、ほとんどのセンチネルの同意が必要であり、これには分散選出の問題が伴います。
一部のセンチネル ノードがハングアップした場合でも、センチネル クラスターは引き続き正常に動作します。これは、高可用性メカニズムの重要な部分であるフェイルオーバー システム自体が単一ポイントである場合、非常に混乱するためです。 。
Sentinel に関する中心的な知識
Sentinel の堅牢性を確保するには、少なくとも 3 つのインスタンスが必要です。
Sentinel redis マスター/スレーブ デプロイメント アーキテクチャは、データ損失ゼロを保証するものではなく、redis クラスターの高可用性のみを保証します。
Sentinel redis マスター/スレーブの複雑なデプロイメント アーキテクチャについては、テスト環境と本番環境の両方で十分なテストと訓練を実施するようにしてください。
29. 公式 Redis クラスター ソリューション (サーバー側ルーティング クエリ)
Redis クラスター モードの動作原理について説明していただけますか?クラスターモードでは、Redis のキーはどのように扱われますか?分散アドレス指定のアルゴリズムは何ですか?一貫性のあるハッシュ アルゴリズムをご存知ですか?
はじめに
Redis Cluster はサーバー側のシャーディング テクノロジであり、バージョン 3.0 で正式に利用可能になります。 Redis Cluster は一貫したハッシュを使用せず、合計 16384 個のスロットに分割されるスロットの概念を使用します。リクエストを任意のノードに送信すると、リクエストを受信したノードは実行のために正しいノードにクエリ リクエストを送信します。
プログラムの説明
ハッシュ化を通じて、データがシャーディングでは、各ノードが特定のハッシュ スロット (ハッシュ値) 範囲にデータを均等に保存し、デフォルトで 16384 個のスロットが割り当てられます。
#各データ シャードは、複数のノード上の複数の相互マスター/スレーブに保存されますデータは最初にマスター ノードに書き込まれ、その後スレーブ ノードに同期されます (ブロック同期の構成をサポート)同じシャード内の複数のノード間のデータは一貫性を維持しません読み取り時データを拡張する場合、クライアントが操作するキーがノード上に割り当てられていない場合、redis はステアリング指示を返し、正しいノードを指します。その一部は新しいノードに送られます。Redis クラスター アーキテクチャでは、各 Redis は 2 つのポート番号 (1 つは 6379、もう 1 つはポート番号に 1w を加えたもの (16379 など)) を開く必要があります。 16379 ポート番号はノード間の通信、つまりクラスタバス通信に使用され、障害検出、構成更新、フェイルオーバー認可に使用されます。クラスター バスは、ノード間の効率的なデータ交換のために別のバイナリ プロトコルであるゴシップ プロトコルを使用し、占有するネットワーク帯域幅と処理時間を削減します。ノード間の内部通信メカニズム
(基本的な通信原理) クラスターのメタデータを維持するには、集中プロトコルとゴシップ プロトコルの 2 つの方法があります。ゴシップ プロトコルは、Redis クラスター ノード間の通信に使用されます。
分散アドレッシング アルゴリズム
ハッシュ アルゴリズム (一括キャッシュ再構築)
一貫性のあるハッシュ アルゴリズム (自動キャッシュ移行) 仮想ノード (自動負荷分散)Redis クラスターのハッシュ スロット アルゴリズム利点
中央アーキテクチャがなく、動的拡張をサポートし、ビジネスに対して透過的です
Sentinel の監視機能と自動フェイルオーバー (フェイルオーバー) 機能を搭載しています。クライアントはクラスター内のすべてのノードに接続する必要はなく、クラスター内の利用可能なノードに接続するだけです。高パフォーマンス、クライアントは redis サービスに直接接続されるため、プロキシの損失がなくなります。 #欠点運用とメンテナンスも非常に複雑で、データ移行には手動介入が必要です番号 0 のみ使用可能 データベース
バッチ操作 (パイプライン操作) をサポートしません
分散ロジックとストレージ モジュールの結合など
30、クライアント-ベースの割り当て
はじめに
Redis シャーディングは、以前は業界で一般的に使用されていたマルチ Redis インスタンスのクラスタリング方法です。 Redis Clusterが出てきました。主なアイデアは、ハッシュ アルゴリズムを使用して Redis データのキーをハッシュすることであり、ハッシュ関数を通じて、特定のキーが特定の Redis ノードにマッピングされます。 Java Redis クライアントは jedis を駆動し、Redis シャーディング機能をサポートします。つまり、ShardedJedis と ShardedJedisPool をキャッシュ プールと組み合わせたものです。
利点利点は、非常に優れていることです。シンプルでサーバー上の Redis インスタンスは互いに独立しており、無関係です。各 Redis インスタンスは単一サーバーのように実行され、直線的に拡張するのが非常に簡単で、システムは非常に柔軟です #デメリット
シャーディング処理によるクライアント側では、さらなる拡張により運用保守に課題が生じます。クライアント側シャーディングは、ノードの動的な追加と削除をサポートしていません。サーバーの Redis インスタンス グループのトポロジが変更されると、各クライアントを更新して調整する必要があります。接続を共有できません。アプリケーションの規模が大きくなると、リソースの無駄が発生して最適化が制限されます。
31. プロキシ サーバーに基づくシャーディング
#はじめに
クライアントはプロキシ コンポーネントにリクエストを送信し、プロキシはクライアントのデータを解析してリクエストを正しいノードに転送します。最後に結果をクライアントに返信します。
特徴
透過的なアクセスにより、ビジネス プログラムはバックエンド Redis インスタンスやスイッチング コストを気にする必要がありません。低い
プロキシ ロジックストレージ ロジックから分離されています
プロキシ層にはもう 1 つの転送があり、パフォーマンスが若干失われます
業界のオープン ソース ソリューション
Twtter オープン ソース Twemproxy
Wandoujia オープン ソース Codis
32. Redis マスター/スレーブ アーキテクチャ
単一-machine redis は数万から数万の QPS を伝送できます。キャッシュの場合、通常、高い読み取り同時実行性をサポートするために使用されます。そのため、アーキテクチャは 1 つのマスターと複数のスレーブからなるマスター スレーブ アーキテクチャとなっており、マスターは他のスレーブ ノードへのデータの書き込みとコピーを担当し、スレーブ ノードは読み取りを担当します。すべての読み取りリクエストはスレーブ ノードに送信されます。これにより、水平方向の拡張も簡単に実現でき、 は高い読み取り同時実行性をサポートします。
redis レプリケーションのコアメカニズム
redis はデータをスレーブ ノードに非同期的にレプリケートしますが、redis2.8 以降、スレーブ ノードは毎回レプリケートするデータの量を定期的に確認します。マスター ノードは複数のスレーブ ノードで構成できます;
スレーブ ノードは他のスレーブ ノードに接続することもできます;
スレーブ ノードがレプリケートするとき、スレーブ ノードは通常の動作をブロックしません。マスター ノード。;
スレーブ ノードは、コピー時に自身のクエリ操作をブロックしません。古いデータ セットを使用してサービスを提供します。ただし、コピーが完了したら、古いデータ セットを削除する必要があります。新しいものをロードします。データ セット、外部サービスはこの時点で一時停止されます。
スレーブ ノードは、主に水平方向の拡張と読み取りと書き込みの分離に使用されます。拡張されたスレーブ ノードにより、読み取りスループットが向上します。
マスター/スレーブ アーキテクチャを採用する場合、マスター ノードの永続性を有効にする必要があることに注意してください。スレーブ ノードをマスター ノードのデータ ホット バックアップとして使用することは推奨されません。その場合、マスターの永続性をオフにすると、マスターがクラッシュして再起動したときにデータが空になり、スレーブ ノードのデータがレプリケートされるとすぐに失われる可能性があるためです。
さらに、マスターのさまざまなバックアップ計画も実行する必要があります。すべてのローカル ファイルが失われた場合に備えて、バックアップから rdb を選択してマスターを復元します。これにより、後で説明する高可用性メカニズムが採用されている場合でも、起動時にデータが存在することが保証されます。ノードは自動的に引き継がれる可能性がありますが、センチネルがマスター障害を検出する前にマスター ノードが自動的に再起動する可能性もあり、それによって上記のスレーブ ノード データがすべて消去される可能性もあります。
Redis マスター/スレーブ レプリケーションの中心原則
スレーブ ノードが起動すると、PSYNC コマンドがマスター ノードに送信されます。 スレーブ ノードがマスター ノードに初めて接続する場合、完全な再同期フル コピーがトリガーされます。このとき、マスターはバックグラウンド スレッドを開始し、RDB スナップショット ファイルの生成を開始します。
同時に、クライアントから新しく受信した書き込みコマンドはすべてメモリにキャッシュされます。 RDB ファイルが生成された後、マスターは RDB をスレーブに送信し、スレーブは最初に RDB をローカル ディスクに
書き込み、次にローカル ディスクからメモリにロードします。次に、マスターはメモリにキャッシュされた書き込みコマンドをスレーブに送信し、スレーブもデータを同期します。 スレーブノードとマスターノードの間でネットワーク障害が発生し、接続が切断された場合、自動的に再接続され、接続後、マスターノードは欠落しているデータのみをスレーブにコピーします。
#プロセス原理
SYNC コマンドを受信した後、メイン ライブラリはバックグラウンド (RDB 永続化プロセス) でスナップショットの保存を開始し、その間に受信した書き込みコマンドをキャッシュします。完了すると、メイン Redis はスナップショット ファイルを保存します。そして、キャッシュされたすべての書き込みコマンドがスレーブ Redis に送信されます。#スレーブ Redis から受信した後、スナップショット ファイルがロードされ、受信したキャッシュされたコマンドが実行されます。
その後、マスター Redis が書き込みコマンドを受信するたびに、データの一貫性を確保するために Redis からコマンドが送信されます
欠点すべてのスレーブ ノードデータのレプリケーションと同期はマスター ノードによって処理されます。マスター ノードの負荷が高すぎる場合は、マスター/スレーブ構造を使用して問題を解決してください。
33. マスター/スレーブ レプリケーションとはRedis クラスターのモデル?一部のノードに障害が発生した場合、またはほとんどのノードが通信できなくなった場合でもクラスターを引き続き使用できるようにするために、クラスターはマスター/スレーブ レプリケーション モデルを使用し、各ノードには N-1 個のレプリカが存在します
34. Redis は運用環境にどのようにデプロイされますか?redis クラスター、10 台のマシン、5 台のマシンは redis マスター インスタンスでデプロイされ、他の 5 台のマシンは redis スレーブ インスタンスでデプロイされます。各マスター インスタンスにはスレーブ インスタンスがあり、5 つのノードは外部読み取りおよび書き込みサービスを提供します。 1 つのノードの書き込みピーク QPS は 1 秒あたり 50,000 に達する可能性があり、5 台のマシンの最大読み取りおよび書き込みリクエスト/秒は 250,000 です。 マシンの構成は何ですか? 32G メモリ、8 コア CPU、1T ディスクですが、redis プロセスには 10G メモリが割り当てられます。一般的なオンライン運用環境では、redis メモリが 10G を超えないようにしてください。10G を超えると問題が発生する可能性があります。 5 台のマシンが外部読み取りおよび書き込みを提供し、合計 50g のメモリを搭載します。 各マスター インスタンスにはスレーブ インスタンスがあるため、可用性が高くなります。いずれかのマスター インスタンスがダウンすると、自動的にフェイルオーバーされ、Redis スレーブ インスタンスが自動的にマスター インスタンスになり、読み取りおよび書き込みサービスを提供し続けます。 . . どのようなデータをメモリに書き込んでいますか?各データのサイズはどれくらいですか?商品データは、各データが10kbです。 100個のデータは1mb、10万個のデータは1gです。メモリ上には200万個の商品データが常駐しており、占有メモリは20gと全メモリの50%未満に過ぎません。現在のピーク時のリクエスト数は 1 秒あたり約 3,500 です。 実際、大企業にはキャッシュ クラスターの運用と保守を担当するインフラストラクチャ チームが存在します。 35. Redis ハッシュ スロットの概念について話しますか? Redis クラスターは一貫したハッシュを使用しませんが、ハッシュ スロットの概念を導入しています。Redis クラスターには 16384 のハッシュ スロットがあります。各キーは、CRC16 チェックに合格した後、16384 のモジュロを取ることによって決定されます。スロットを配置する場合、クラスター内の各ノードはハッシュ スロットの一部を担当します。 36. Redis クラスターで書き込み操作は失われますか?なぜ？ Redis はデータの強い整合性を保証しません。つまり、実際には、特定の条件下でクラスターが書き込み操作を失う可能性があります。 37. Redis クラスターはどのようにレプリケートされますか? 非同期レプリケーション 38. Redis クラスター内のノードの最大数はどれくらいですか? 16384 39. Redis クラスターのデータベースを選択するにはどうすればよいですか? Redis クラスターは現在データベースを選択できず、デフォルトはデータベース 0 です。 9. パーティション 40. Redis はシングルスレッドですが、マルチコア CPU の使用率を改善するにはどうすればよいですか? 複数の Redis インスタンスを同じサーバーにデプロイし、それらを異なるサーバーとして使用できます。いずれにしても 1 つのサーバーでは不十分な場合があるため、複数の CPU を使用したい場合は、シャーディングを検討できます。 41. Redis パーティショニングが必要な理由は何ですか? パーティショニングにより、Redis はより大きなメモリを管理できるようになり、Redis はすべてのマシンのメモリを使用できるようになります。パーティションがないと、最大 1 台のマシンのメモリしか使用できません。パーティショニングを使用すると、コンピュータを追加するだけで Redis のコンピューティング能力を 2 倍にすることができ、コンピュータとネットワーク カードを追加すると Redis のネットワーク帯域幅も飛躍的に増加します。 42.どのような Redis パーティション実装ソリューションが利用できるかご存知ですか? クライアント側のパーティショニングとは、データがどの Redis ノードに保存されるか、またはどの Redis ノードから読み取られるかをクライアントがすでに決定していることを意味します。ほとんどのクライアントはすでにクライアント側パーティショニングを実装しています。 エージェントの分割とは、クライアントがリクエストをエージェントに送信し、エージェントがデータの書き込みまたは読み取り先のノードを決定することを意味します。エージェントは、パーティション ルールに基づいてリクエストする Redis インスタンスを決定し、Redis 応答結果に基づいてクライアントにインスタンスを返します。 Redis と memcached のプロキシ実装は Twemproxy です。 クエリ ルーティング (クエリ ルーティング) とは、クライアントが任意の Redis インスタンスをランダムにリクエストし、Redis がそのリクエストを正しい Redis ノードに転送することを意味します。 Redis Cluster はハイブリッド形式のクエリ ルーティングを実装していますが、ある Redis ノードから別の Redis ノードにリクエストを直接転送するのではなく、クライアントの助けを借りて正しい Redis ノードに直接リダイレクトします。 43. Redis パーティショニングの欠点は何ですか? 複数のキーを含む操作は通常サポートされていません。たとえば、2 つのコレクションは異なる Redis インスタンスに保存されている可能性があるため、それらを交差させることはできません (実際には、この状況を解決する方法はありますが、交差コマンドを直接使用することはできません)。 複数のキーを同時に操作する場合、Redis トランザクションは使用できません。 パーティション化で使用される粒度はキーであり、データ セットの保存に非常に長いソート キーを使用することはできません。 (パーティショニングの粒度は key であるため、非常に大きなソート セットのような単一の巨大なキーでデータセットをシャーディングすることはできません) パーティションを使用する場合、データ処理は非常に複雑になります。たとえば、バックアップするには、別の Redis インスタンスから開始する必要があります。ホストと同時に RDB/AOF ファイルを収集します。 パーティション化時の動的な拡張または縮小は、非常に複雑になる可能性があります。 Redis クラスターは、実行時に Redis ノードを追加または削除するため、ユーザーに対して最大限透過的なデータのリバランスを実現できますが、他の一部のクライアント パーティショニングまたはプロキシ パーティショニング方法では、この機能がサポートされていません。ただし、この問題をより適切に解決できるプレシャーディング テクノロジもあります。 10. 分散の問題 44. Redis は分散ロックを実装します Redis はシングルプロセスシングルスレッドモードであり、キューモードを使用してアクセスします同時にシリアル アクセスになり、複数のクライアントの Redis への接続間に競合がなくなり、SETNX コマンドを使用して Redis に分散ロックを実装できます。 キーが存在しない場合に限り、キーの値を value に設定します。指定されたキーがすでに存在する場合、SETNX は何も行いません。 SETNX は「SET if Not eXists」(存在しない場合は SET) の略です。 戻り値: 設定が成功すると1が返ります。セットアップは失敗し、0 を返します。 SETNX を使用して同期ロックを完了するためのプロセスと事項は次のとおりです。 SETNX コマンドを使用して、 0 が返された場合 (キーが存在し、ロックがすでに存在した場合)、取得は失敗し、それ以外の場合は取得は成功します。 ロックを取得した後にプログラム内で例外が発生し、SETNX コマンドの呼び出し時に他のスレッド/プロセスが常に 0 を返してデッドロック状態になることを防ぐために、「適切な」有効期限を設定する必要があります。キー。 ロックを解除し、DEL コマンドを使用してロック データを削除します。 45. Redis の Key の同時競合問題を解決する方法 Redis の Key のいわゆる同時競合問題は、複数のシステムが動作することです。同時にキーを入力しましたが、最終的には、実行順序が予期した順序と異なるため、異なる結果が生じます。 解決策を推奨します: 分散ロック (Zookeeper と Redis の両方が分散ロックを実装できます)。 (Redis でキーの同時競合がない場合は、分散ロックを使用しないでください。パフォーマンスに影響します。) Zookeeper の一時的に順序付けされたノードに基づく分散ロック。一般的な考え方は、各クライアントが特定のメソッドをロックすると、Zookeeper 上のメソッドに対応する指定されたノードのディレクトリに、一意の瞬間順序付けされたノードが生成されるというものです。ロックを取得するかどうかを決定する方法は非常に簡単で、順序付けされたノードの中で最も小さいシーケンス番号を決定するだけで済みます。ロックが解除されたら、一時ノードを削除するだけです。同時に、サービスのダウンタイムにより解放できないロックによって引き起こされるデッドロックの問題を回避できます。ビジネスプロセスが完了したら、該当する子ノードを削除してロックを解除します。 実際には、もちろん信頼性が最優先事項です。したがって、Zookeeper が最初に推奨されます。 46. 分散Redisは初期段階で行うべきでしょうか、それとも規模が大きくなった後の段階で行うべきでしょうか?なぜ？ Redis は非常に軽量であるため (単一インスタンスで使用するメモリは 1M のみ)、将来の拡張を防ぐ最善の方法は、最初にさらに多くのインスタンスを起動することです。サーバーが 1 台しかない場合でも、パーティションを使用して同じサーバー上で複数のインスタンスを起動することで、最初から Redis を分散方式で実行できます。 最初にさらにいくつかの Redis インスタンス (32 インスタンスや 64 インスタンスなど) をセットアップします。これはほとんどのユーザーにとって面倒かもしれませんが、長期的には犠牲にする価値があります。 この場合、データが増大し続け、より多くの Redis サーバーが必要になった場合、必要なのは Redis インスタンスをあるサービスから別のサーバーに移行するだけです (再パーティション化を考慮する必要はありません)。別のサーバーを追加したら、Redis インスタンスの半分を最初のマシンから 2 番目のマシンに移行する必要があります。 47. RedLock とは Redis 公式 Web サイトでは、Redlock と呼ばれる、Redis に基づく分散ロックを実装するための権威ある方法が提案されています。この方法は、オリジナルの単一の方法よりも優れています。 -node アプローチの方が安全です。次の機能を保証できます: 安全機能: 相互排他的アクセス、つまり、常に 1 つのクライアントのみがロックを取得できます デッドロックの回避: 最終的には、クライアントがロックを取得できるため、最初にリソースをロックしていたクライアントがクラッシュしたり、ネットワークの分断が発生したりしても、デッドロックは発生しません。 フォールト トレランス: Asほとんどの Redis ノードが生きている限り、通常どおりサービスを提供できます 11. キャッシュ例外 48. キャッシュ雪崩 キャッシュ雪崩とは、同時に大規模な領域をキャッシュすることを指します。したがって、後続のリクエストがデータベースに降りかかり、データベースが短期間に大量のリクエストに耐えて崩壊することになります。 解決策: キャッシュされたデータの有効期限をランダムに設定して、多数のデータが同時に期限切れになるのを防ぎます。 一般に、同時実行の量が特に大きくない場合、最も一般的に使用される解決策はロック キューイングです。 キャッシュされた各データに対応するキャッシュ タグを追加し、キャッシュが無効かどうかを記録します。キャッシュ タグが無効な場合は、データ キャッシュを更新します。 49. キャッシュの侵入 キャッシュの侵入とは、キャッシュにもデータベースにも存在しないデータを指し、すべてのリクエストがデータベースに到達し、データベースがダウンします。短期間に大量のリクエストがあったためにクラッシュしました。 解決策: ユーザー認証検証、ID の基本検証、ID の直接傍受などの検証をインターフェイス層に追加します キャッシュから取得できないデータはデータベースには取得されません。このとき、キーと値のペアをkey-nullとして記述することもできます。キャッシュの有効時間は30秒など短く設定することもできます（設定が長すぎると通常では使用できなくなります）。これにより、攻撃ユーザーが同じ ID を繰り返し使用してブルート フォース攻撃を行うことを防ぐことができます。 ブルーム フィルターを使用して、すべての可能なデータを十分な大きさのビットマップにハッシュします。存在してはいけないデータは、このビットマップによってハッシュされます。それを傍受し、これにより、基盤となるストレージ システムに対するクエリの負荷を回避できます。 追加: ビットマップとブルームフィルターという極限レベルに達した空間利用。 ビットマップ: 通常はハッシュ テーブルです 欠点は、ビットマップは各要素について 1 ビットの情報しか記録できないことです。追加の関数を完成させたい場合は、残念ながら、それはより多くの空間と時間を犠牲にすることによってのみ達成できるのです。 ブルーム フィルター (推奨) k(k>1)k(k>1) の独立したハッシュ関数を導入して、指定された空間と誤判定率の下で、要素の重みを決定するプロセスが完了します。 利点は、スペース効率とクエリ時間が一般的なアルゴリズムよりもはるかに高いことですが、欠点は、一定の誤認識率と削除が難しいことです。 ブルーム フィルター アルゴリズムの中心となるアイデアは、複数の異なるハッシュ関数を使用して「競合」を解決することです。 ハッシュには競合 (衝突) の問題があり、同じハッシュを使用して取得された 2 つの URL の値が同じになる可能性があります。競合を減らすために、さらにいくつかのハッシュ値を導入できます。ハッシュ値の 1 つから、要素がセットに含まれていないと結論付けられた場合、その要素は間違いなくセットに含まれていません。すべてのハッシュ関数が要素がセット内にあることを示す場合にのみ、要素がセット内に存在することを確認できます。これがブルームフィルターの基本的な考え方です。 ブルーム フィルターは通常、大規模なデータ コレクションに要素が存在するかどうかを判断するために使用されます。 50. キャッシュの内訳 キャッシュの内訳とは、キャッシュ内にはないがデータベース内にあるデータを指します (通常、キャッシュ時間は期限切れ)、このとき、同時ユーザーの数が多かったために、読み取りキャッシュは同時にデータを読み取ることができず、同時にデータベースにアクセスしてデータを取得したため、データベースの負荷が瞬時に増加しました。 、過度の圧力を引き起こします。キャッシュ雪崩とは異なり、キャッシュ ブレークダウンは同じデータに対する同時クエリを指します。キャッシュ雪崩とは、異なるデータの有効期限が切れ、大量のデータが見つからないため、データベースが検索されることを意味します。 解決策 ホットスポット データが期限切れにならないように設定します。 ミューテックス ロック、ミューテックス ロックを追加します 51. キャッシュの予熱 キャッシュの予熱とは、システムがオンラインになった後、関連するキャッシュ データを直接ロードすることを意味します。キャッシュ システムに。このようにして、最初にデータベースにクエリを実行し、ユーザーが要求したときにデータをキャッシュするという問題を回避できます。ユーザーは、予熱されたキャッシュ データを直接クエリします。 解決策: キャッシュ更新ページを直接作成し、オンラインになったときに手動で実行します。 データ量が大きくないため、プロジェクトの開始時に実行できます 必要に応じて自動的にロードします; キャッシュを定期的に更新します; 52. キャッシュのダウングレード 数値が下がったとき訪問者数が急激に増加し、サービスの問題 (応答時間が遅い、または応答しない場合など) が発生したり、非コア サービスがコア プロセスのパフォーマンスに影響を及ぼしたりする場合、サービスが損なわれた場合でも、サービスが引き続き利用可能であることを確認する必要があります。システムは、いくつかの重要なデータに基づいて自動的にダウングレードすることも、手動でダウングレードできるようにスイッチを構成することもできます。 , キャッシュ ダウングレードの最終的な目標は、たとえ損失があったとしても、コア サービスが確実に利用できるようにすることです。また、一部のサービスはダウングレードできません (ショッピング カートへの追加、チェックアウトなど)。 ダウングレードする前に、システムが兵士を失い、指揮官を維持できるかどうかを確認する必要があります。これにより、何を死ぬまで守る必要があり、何をダウングレードできるかを分類する必要があります。たとえば、以下を参照できます。ログ レベル設定計画: 一般: たとえば、一部のサービスは、ネットワーク ジッターが原因でタイムアウトしたり、サービスがオンラインになり、自動的にダウングレードされる可能性があります。 警告: 一部のサービスは、一定の期間にわたって成功率が変動します (95 ～ 100% など)。自動的にダウングレードするか手動でダウングレードして、アラームを送信できます。 エラー:たとえば、可用性率が 90% 未満である場合、データベース接続プールが枯渇している場合、またはアクセス数がシステムが耐えられる最大しきい値まで突然急増した場合など、状況に応じて自動的にダウングレードすることも、手動でダウングレードすることもできます。状況に応じて; 重大なエラー:たとえば、特別な理由によりデータが間違っている場合は、この緊急手動ダウングレードが必要です。 サービスのダウングレードの目的は、Redis サービスの障害によってデータベースに雪崩の問題が発生するのを防ぐことです。したがって、重要でないキャッシュ データについては、サービスのダウングレード戦略を採用できます。たとえば、一般的なアプローチは、Redis に問題がある場合、データベースにクエリを実行する代わりに、デフォルト値をユーザーに直接返すことです。 53. ホット データとコールド データ ホット データとキャッシュのみが価値があります。 コールド データの場合、データの大部分は再度アクセスされる前にメモリから搾り出される可能性があり、メモリを占有するだけでなく、価値もほとんどありません。頻繁に変更されるデータの場合は、状況に応じてキャッシュの使用を検討してください。 当社の IM 製品、誕生日の挨拶モジュール、その日の誕生日リストなどのホット データの場合、キャッシュは数十万回読み取られる可能性があります。回。別の例として、ナビゲーション製品では、ナビゲーション情報をキャッシュし、将来的にそれを何百万回も読み取る可能性があります。 キャッシュは、更新前にデータが少なくとも 2 回読み取られる場合にのみ意味を持ちます。これは最も基本的な戦略ですが、キャッシュが有効になる前に失敗すると、あまり意味がありません。 キャッシュが存在せず、変更頻度が非常に高いが、キャッシュを考慮する必要があるシナリオはどうなるでしょうか?持っている！たとえば、この読み取りインターフェイスはデータベースに多大な負荷をかけますが、ホット データでもあります。このとき、いいね数、コレクション数、アシスタント製品の 1 つの共有。これは非常に一般的なホット データですが、変化し続けます。現時点では、データベースへの負荷を軽減するために、データを Redis キャッシュに同期的に保存する必要があります。 54. キャッシュ ホットスポット キー キャッシュ内のキー (プロモーション製品など) が特定の時点で期限切れになると、その時点ではたまたま正しいものになります。この時点。このキーには多数の同時リクエストがあります。これらのリクエストは、キャッシュの有効期限が切れていることを検出すると、通常、バックエンド DB からデータをロードしてキャッシュにリセットします。このとき、大量の同時リクエストが発生する可能性があります。バックエンド DB を瞬時に圧倒します。 解決策: キャッシュ クエリをロックします。KEY が存在しない場合はロックし、DB をキャッシュにチェックインしてロックを解除します。そうでない場合はロックを解除します。プロセスは、ロックがかかるまで待機し、ロックが解除されてデータが返されるか、DB クエリを入力するのを待ちます。 共通ツール 55. Java クライアントとはRedis でサポートされていますか?公式で推奨されているのはどれですか？ Redisson、Jedis、レタスなど。公式では Redisson を使用することを推奨しています。 56. Redis と Redisson の関係は何ですか? Redisson は、ユーザーが分散環境、ConcurrentMap、List で一部の Java オブジェクト (ブルーム フィルター、BitSet、Set、SetMultimap、ScoredSortedSet、SortedSet、Map) を簡単に実装できるようにする高度な分散調整 Redis クライアントです。 、ListMultimap、Queue、BlockingQueue、Deque、BlockingDeque、セマフォ、Lock、ReadWriteLock、AtomicLong、CountDownLatch、パブリッシュ/サブスクライブ、HyperLogLog)。 57. ジェディスとレディソンの長所と短所は何ですか? Jedis は、Java の Redis によって実装されたクライアントです。その API は、Redis コマンドに対する比較的包括的なサポートを提供します。Redisson は、分散型でスケーラブルな Java データ構造を実装します。Jedis と比較して、その機能は比較的シンプルです。文字列操作はサポートされておらず、並べ替え、トランザクション、パイプライン、パーティションなどの Redis 機能もサポートされていません。 Redisson の目的は、ユーザーがビジネス ロジックの処理に集中できるように、ユーザーの懸念事項を Redis から分離することを促進することです。 その他の問題 58、Redis との違いMemcached どちらも非リレーショナル メモリ キー/値データベースです。現在、企業は一般的に Redis を使用してキャッシュを実装しており、Redis 自体はますます強力になっています。 Redis と Memcached には次の主な違いがあります: #(1) memcached のすべての値は単純な文字列であり、redis はその代わりとして、より豊富なデータ型をサポートします (2) redis は memcached よりもはるかに高速です (3) redis はデータを永続化できます 59. キャッシュの二重書き込みとデータベース データの整合性を確保する方法? キャッシュを使用する限り、ストレージの二重化、キャッシュとデータベースの二重書き込みが発生する可能性があります。二重書き込みを使用している限り、データの一貫性の問題が確実に発生します。一貫性の問題?? 一般的に、システムがキャッシュ データベースの一貫性を厳密に要求していない場合、キャッシュはデータベースとわずかに不一致になることがあります。この解決策は実行しないことをお勧めします。読み取りリクエスト文字列と書き込みリクエスト文字列のシリアル化 シリアル化後は、システムのスループットが大幅に低下し、使用量が通常の状態よりも大幅に低下します。 . オンライン リクエストをサポートするには、数倍のマシンをダウンロードします。 もう 1 つの方法は、一時的に不整合を発生させることですが、発生する可能性は非常に低いです。まずデータベースを更新してからキャッシュを削除します。 #60. Redis の一般的なパフォーマンスの問題と解決策は? マスターは、メモリ スナップショットや AOF ログ ファイルなどの永続化作業を行わないことをお勧めします。特に、永続化のためにメモリ スナップショットを有効にしないでください。 データが重要な場合、スレーブは AOF バックアップ データを有効にし、ポリシーは 1 秒に 1 回同期します。 マスター/スレーブ レプリケーションの速度と接続の安定性を考慮すると、スレーブとマスターが同じ LAN 内にあることが最適です。 ストレスのかかるメイン ライブラリにスレーブ ライブラリを追加しないようにしてください マスターは BGREWRITEAOF を呼び出して AOF ファイルを書き換えます。AOF は書き換え中に大量の CPU リソースとメモリ リソースを占有するため、サービス障害が発生します。 . 負荷が高すぎるため、サービスを一時停止しています。 マスターの安定性を考慮すると、マスター/スレーブ レプリケーションにはグラフ構造を使用せず、一方向のリンク リスト構造、つまりマスターとスレーブの関係を使用する方が安定します。マスター 61. Redis はなぜ Windows バージョンを正式に提供しないのですか? 現在の Linux バージョンは非常に安定しており、ユーザー数も多いため、互換性やその他の問題が発生する Windows バージョンを開発する必要はありません。 62. 文字列型の値が格納できる最大容量はどれくらいですか? 512M 63. Redis はどのようにして大量のデータを挿入しますか? Redis 2.6 以降、redis-cli は、大量のデータ挿入作業を実行するためのパイプ モードと呼ばれる新しいモードをサポートします。 64. Redis に 1 億個のキーがあり、100,000 個のキーが固定の既知のプレフィックスで始まると仮定します。すべてを見つけるにはどうすればよいでしょうか? keys コマンドを使用して、指定したモードのキー リストをスキャンします。 次に、相手は「この Redis がオンライン ビジネスにサービスを提供している場合、keys コマンドの使用にはどのような問題がありますか?」と尋ねました。 現時点では、redis の重要な機能の 1 つである redis のシングル スレッドについて答える必要があります。キー命令によりスレッドが一定期間ブロックされ、オンライン サービスが一時停止されます。命令が実行されるまでサービスは復元できません。このとき、scan コマンドを使用できます。scan コマンドは、指定したモードのキーリストをブロックせずに抽出できますが、一定の確率で重複が発生します。クライアントで 1 回実行するだけですが、全体の所要時間は長くなります。直接使用するよりも長くなります。keys コマンドは長いです。 65. Redis を使用して非同期キューを作成したことがありますか?それはどのように実装されましたか? リスト タイプを使用してデータ情報を保存し、rpush はメッセージを生成し、lpop はメッセージを消費します。lpop にメッセージがない場合は、一定時間スリープして、情報があるかどうかを確認できます。スリープしたくない場合は、 blpop を使用できます。情報がない場合は、情報が到着するまでブロックされます。 Redis は、Pub/Sub トピック サブスクリプション モデルを通じて 1 つのプロデューサーと複数のコンシューマーを実装できます。もちろん、いくつかの欠点があります。コンシューマーがオフラインになると、生成されたメッセージは失われます。 66. Redis は遅延キューをどのように実装しますか? sortedset を使用し、タイムスタンプをスコアとして使用し、メッセージ コンテンツをキーとして使用し、zadd を呼び出してメッセージを生成し、コンシューマは zrangbyscore を使用してポーリング処理用に n 秒前のデータを取得します。 67. Redis のリサイクル プロセスはどのように機能しますか? 68. Redis のリサイクルにはどのようなアルゴリズムが使用されていますか? #LRU アルゴリズム。 
以上が2023年最新版 Redis面接68問（集）の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
