Redis の分散キャッシュに関するインタビューの質問をいくつか共有します (回答分析付き)

この記事では、回答の分析を含め、Redis の分散キャッシュに関するインタビューの質問をいくつか紹介します。一定の参考値があるので、困っている友達が参考になれば幸いです。

インタビューの質問

---

redis と memcached の違いは何ですか? Redis のスレッド モデルとは何ですか? Redis が単一スレッドで高い同時実行をサポートできるのはなぜですか?

面接官の心理分析

これは、redis について尋ねるときの最も基本的な質問であり、redis の最も基本的な内部部分です。特徴としては、redis は実際には シングルスレッド作業モデル であるということです。これを知らないと、後から redis を使って遊んだときに、何か問題が発生した場合に何も分からなくなるのではないでしょうか?

面接官が redis と memcached の違いについて質問する可能性もありますが、初期の頃は memcached が大手インターネット企業でよく使われていたキャッシュ ソリューションでしたが、近年では基本的に redis になっています。 、memcached を使用している企業はほとんどありません。 [関連する推奨事項: Redis ビデオ チュートリアル ]

面接の質問分析

Redis の違いは何ですかそしてmemcached?

redis は複雑なデータ構造をサポートします

memcached と比較して、redis はより多くのデータ構造を持ち、より豊富なデータ操作をサポートできます。より複雑な構造と操作をサポートするキャッシュが必要な場合は、redis が良い選択になります。

redis はクラスター モードをネイティブにサポートします

redis3 でデータを入力します。

パフォーマンスの比較

redis は シングルコア のみを使用するのに対し、memcached は マルチコア を使用できるため、平均すると、redis はそれぞれのコアに少量のデータを保存します。 core memcached よりも高いパフォーマンス。 100k を超えるデータの場合、memcached のパフォーマンスは Redis よりも高くなります。 Redis は最近ビッグ データ ストレージのパフォーマンスに最適化されていますが、それでも memcached よりは若干劣ります。

redis のスレッド モデル

redis は内部的にファイル イベント ハンドラーを使用します ファイル イベント ハンドラー. このファイル イベント ハンドラーはシングルスレッドであるため、Redis はシングルスレッドモデルと呼ばれます。 IO 多重化メカニズムを使用して複数のソケットを同時にリッスンし、イベントを生成するソケットをメモリ キューにプッシュします。イベント ディスパッチャーは、ソケット上のイベント タイプに基づいて、処理する対応するイベント プロセッサを選択します。

ファイル イベント ハンドラーの構造には、次の 4 つの部分が含まれます。

• 複数のソケット
• IO マルチプレクサ
• ファイル イベント ディスパッチ デバイス
• イベント プロセッサ (接続応答プロセッサ、コマンド要求プロセッサ、コマンド応答プロセッサ)

複数のソケットが異なる操作を同時に生成することがあり、各操作は異なるファイル イベントに対応しますが、IO マルチプレクサは複数のファイル イベントを監視します。イベントを生成するソケットをキューに入れ、イベント ディスパッチャは毎回キューからソケットを 1 つ取り出し、ソケットのイベント タイプに応じて対応するソケットに渡します。

クライアントと redis の間の通信プロセスを見てみましょう:

通信はソケットを通じて完了することを理解する必要があります。理解していない生徒でも理解できます。まずはソケットネットワークプログラミングを見てみましょう。

まず、redis サーバー プロセスが初期化されると、サーバー ソケットの AE_READABLE イベントが接続応答プロセッサに関連付けられます。

クライアントソケット01は、redisプロセスのサーバーソケットに接続を確立するよう要求します。このとき、サーバーソケットはAE_READABLEイベントを生成します。IO多重化プログラムが生成されたイベントを監視した後、サーバーソケット、ソケットをキューにプッシュします。ファイル イベント ディスパッチャーはキューからソケットを取得し、それを Connection Response Processor に渡します。接続応答ハンドラーは、クライアントと通信できるソケット 01 を作成し、socket01 の AE_READABLE イベントをコマンド要求ハンドラーに関連付けます。

クライアントが set key value リクエストを送信すると仮定します。このとき、redis のソケット 01 は AE_READABLE イベントを生成し、IO マルチプレクサーはソケット 01 にプッシュします。キューにアクセスすると、イベント ディスパッチャは、socket01 によって生成された AE_READABLE イベントをキューから取得します。socket01 の前回の AE_READABLE イベントはコマンド リクエスト プロセッサに関連付けられているため、イベント ディスパッチャはイベントをコマンド要求ハンドラーに送信して処理します。コマンド要求プロセッサは、socket01 の key value を読み取り、自身のメモリに key value の設定を完了します。操作が完了すると、socket01 の AE_WRITABLE イベントがコマンド応答ハンドラーに関連付けられます。

この時点でクライアントが戻り結果を受け取る準備ができている場合、redis のソケット 01 は AE_WRITABLE イベントを生成し、これもキューにプッシュされます。イベント ディスパッチャは、関連するコマンド応答プロセッサを見つけます。コマンド応答プロセッサは、この操作の結果 (ok など) をソケット 01 に入力し、socket01 の AE_WRITABLE イベントとコマンド応答プロセッサとの関連付けを解放します。

これで通信は完了です。 Redis の通信プロセスについては、『Redis の設計と実装 - Huang Jianhong』を読んで体系的に学習することをお勧めします。

Redis シングルスレッド モデルはなぜこれほど効率的なのでしょうか?

• 純粋なメモリ操作。
• コアは、ノンブロッキング IO 多重化メカニズムに基づいています。
• C 言語の実装 一般に、C 言語で実装されたプログラムはオペレーティング システムに「近く」、実行速度が比較的速くなります。
• シングルスレッドは、マルチスレッドの頻繁なコンテキスト切り替えの問題を回避し、マルチスレッドによって引き起こされる可能性のある競合の問題を防ぎます。

インタビューの質問

---

#edis における同時実行競合の問題とは何ですか?この問題をどうやって解決すればいいでしょうか？ Redis トランザクション用の CAS ソリューションをご存知ですか?

面接官の心理分析

これもオンラインで非常に一般的な問題です。つまり、複数のクライアントが同時に # を書くとき## キーの場合、最初に到着するはずのデータが遅れて到着する可能性があり、データのバージョンが間違っている場合や、複数のクライアントが同時にキーを取得し、値を変更して書き戻す場合があります。が間違っていると、データも間違ってしまいます。

そして、redis 自体には、この問題を自然に解決する CAS のようなオプティミスティック ロック ソリューションがあります。

#面接の質問の分析#ある時点で、複数のシステム インスタンスが特定のキーを更新します。分散ロックは、Zookeeper に基づいて実装できます。各システムは、Zookeeper を通じて分散ロックを取得し、同時に 1 つのシステム インスタンスだけが特定のキーを操作できるようにし、他のユーザーは読み書きできないようにします。

キャッシュに書き込みたいデータはすべて mysql から見つかり、mysql に書き込む必要があります。mysql に書き込むときは、タイムスタンプを保存する必要があります。チェックするときmysql から出力されると、タイムスタンプもチェックアウトされます。

書き込み前に常に、現在の値のタイムスタンプがキャッシュ内の値のタイムスタンプよりも新しいかどうかを

確認します。存在する場合は書き込み可能ですが、そうでない場合は、新しいデータを古いデータで上書きできません。

プログラミング関連の知識について詳しくは、プログラミング ビデオ

をご覧ください。 ！

以上がRedis の分散キャッシュに関するインタビューの質問をいくつか共有します (回答分析付き)の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。