Java 面接の質問 --- Redis②

  1. Redis のマスターとスレーブについて簡単に説明します。
    マスタースレーブとは、Redisをマスターとし、その下にn個のスレーブがぶら下がっており、マスターはデータの書き込みに使用され、書き込み後はスレーブに同期され、スレーブはデータの読み取りに使用されます。Redis のマスター/スレーブには主に 2 つのモードがあります。

1 つのマスターと n 個のスレーブ: 1 つのマスターが n 個のスレーブをハングします。欠点は、これらの n 個のスレーブがすべて同じマスターの下でハングアップされることです。マスターはスレーブまたはスレーブとしてハングアップされ、マスターにはならず、その後、このマスターとスレーブは使用できなくなります。これで、1 つのコマンドのスレーブを手動で実行して、スレーブから新しいマスターを選択できます。マスター
とスレーブの直列接続: A は B の下にハングし、B は同じひずみの下で C をハングします。2
. Redis のマスター/スレーブ レプリケーションの原理は何ですか?

マスターは RDB ファイルを生成してスレーブに送信し、スレーブは RDB を受信後、まずディスクに書き込み、次に RDB 同期データを読み取ります。
3. Redis クラスターのソリューションは何ですか?

Sentinel: 1 つのマスターとスレーブの自動バージョン。上記のマスターはハングアップするため、手動で新しいマスターを選択する必要があります。Sentinel とは、Redis ノードを監視するためのセンチネル クラスターが Redis にあることを意味します。マスターがダウンしていることが判明すると、新しいマスター、つまりマスターに投票します。長所は使いやすいことですが、短所はデータを書き込むマスターが 1 つしかないため、パフォーマンスのボトルネックになりやすいことです。
Redis-cluster: Redis 公式クラスター モード。n 個のマスターがあり、各マスターは n 個のスレーブをハングします。つまり、n 個のマスターとスレーブが存在します。各マスター間でデータは同期されませんが、データを共有することは可能です。データを書き込む場合、データはいずれかのマスターにのみ書き込まれ、その後マスターが属するスレーブに同期されます。データを読み取るときに、そのキーのないノードで操作している場合、コマンドはそのキーを持つノードに転送されます。コマンドを転送する必要があるため、各マスターは通信にゴシップ プロトコルを使用するため、各マスターは 2 つのポートを開く必要があります。たとえば、1 つは 6379、もう 1 つは通信用に 16379 + 10,000 です。redis-cluster の原理は、ハッシュ スロットの概念を採用していることです。合計 16384 個のハッシュ スロットがあり、Redis のマスター ノードに割り当てられます。データを書き込む際には、crc16 アルゴリズムを使用してキーを計算します。そして 16384 の余りを取ると、どのマスターに書き込むべきかが分かります。この方式の利点は、パフォーマンスが良く、動的拡張に対応していることですが、欠点は、0 番のライブラリしか使用できず、パイプライン技術をサポートしていないことです。
クライアントベースのシャーディング: データを書き込むとき、プログラム内でキーが計算され、書き込むノードが決定されます。各 Redis インスタンス間に関連性がなく、直線的に拡張しやすいことがメリットですが、Redis インスタンスの数が増えるとキーマッピングルールの変更が必要になることがデメリットです。
プロキシベースのシャーディング: クライアントリクエストはプロキシに送信され、プロキシはどのノードに送信するかを決定します。利点は、プログラムが Redis ノードの数を気にする必要がなく、キーのマッピング ルールを作成する必要がないことですが、欠点は、追加のプロキシ層が存在し、パフォーマンスが低下することです。一般的なプロキシには、pea pod オープンソース codis や Twitter オープンソース Twemproxy などがあります。
4. 二重書き込みの一貫性にはどのように対処しますか?
二重書き込みの一貫性とは、データベース データと Redis 内のデータの間の一貫性を指します。通常、最初にデータベースが書き込まれ、次に Redis が書き込まれますが、これでは問題が発生します。データベースが書き込まれ、Redis を更新する時間がない場合、リクエストが受信され、Redis 内の古いデータが読み取られます。二重削除遅延戦略を使用して、二重書き込みの一貫性の問題に対処できます。具体的なプロセス:

最初に Redis 内のデータを削除し、
次にデータベースを更新します。
スレッドは一定期間スリープし、
その後 Redis 内のデータを削除します。
データを削除する前に一定期間スリープします。データベースでは、リクエスト B が到着し、データベースの古いデータを削除し、A に DB の更新をリクエストしてから Redis を削除し、B に読み取った古いデータを Redis に書き込むようリクエストしますが、それでもデータベースと Redis データが不一致になります。一定期間スリープすると、リクエスト B がデータベースの読み取りと Redis への書き込みの手順を確実に完了でき、実行後にリクエスト A に Redis の削除をリクエストすると、Redis 内の古いデータを削除できます。したがって、スリープ時間は、リクエスト B のデータベースの読み取りと Redis への書き込みの合計時間よりも長くする必要があります。強い一貫性が必要ない場合、このアプローチはお勧めできません。また、一定期間スリープした場合のエクスペリエンスはあまり良くありません。

  1. 同時に競合するキーの問題にどう対処するか?

同時競合キーとは、複数のクライアントが同じキーを同時に操作することを意味します。分散ロックを使用したり、メッセージ キューを使用してリクエストをシリアル化したり、書き込まれた値にタイムスタンプを追加して判断したりできます。現在時刻より後のタイムスタンプが存在するかどうかに関係なく、存在する場合は書き込まれません。
6. キャッシュアバランシェとは何ですか? の解き方?

キャッシュ雪崩とは、キャッシュの広い領域で同時に障害が発生し、大量のリクエストがデータベースに直接落ちてデータベースを圧倒することを意味します。解決策は、キーに異なる有効期限を設定して失敗を回避し、データベースの操作方法をロックし、リクエストをシリアルにすることです。
7. キャッシュペネトレーションとは何ですか? の解き方?

キャッシュの侵入とは、データベースやキャッシュに存在しないデータに対する大量のリクエストが発生し、データベースが崩壊することです。解決策は、パラメータ検証を適切に実行し、不正なリクエストを直接ブロックすること、ブルーム フィルタを使用してデータベース内のデータをブルーム フィルタにキャッシュし、データベースをリクエストする前にブルーム フィルタにデータがあるかどうかを確認することです。 。
8. キャッシュの内訳とは何ですか? の解き方?

キャッシュのブレークダウンとは、Redis にないキーに対するリクエストが同時に大量に発生し、このキーに対するすべてのリクエストがデータベースに送られ、データベースが崩壊することです。解決策は、ブルーム フィルターを使用し、ホットスポット データを無期限に設定するなどです。
9. 1 億個のキーの中から指定されたプレフィックスを持つキーを見つけるにはどうすればよいですか?

キー プレフィックス*: このメソッドは、クエリが完了するまで Redis をブロックします。
スキャン 0 一致プレフィックス* カウント 10: カーソルを使用し、Redis をブロックしません。これは、10 個の対象となるキーが 0 からクエリされ、2 回目は 10 個の一致プレフィックス * 20 がスキャンされることを意味します。

Guess you like

Origin blog.csdn.net/m0_54861649/article/details/126545339