Redis の高頻度面接の質問 (2023 年最新)

序文

面接の質問なので詳しくは言いませんが、覚えておけば大丈夫です、2年半は幸せになれること間違いなしです。
Java の最新の面接の質問 (Java の基本、コレクション、マルチスレッド、jvm、ロック、アルゴリズム、CAS、Redis、データベース、mybatis、spring、springMVC、springBoot、マイクロサービス)

1.redisとは

C言語で開発された高性能な非リレーショナルデータベースです。

2.redis のストレージ構造は何ですか?

文字列:キーと値のペア。アプリケーション シナリオ: キャッシュ、SMS 確認コードなど。

set key value  //设置值
get key        //获取值

ハッシュ:キーと値のペア。複数のキーと値のペアを保存でき、オブジェクトの保存に適しています。アプリケーション シナリオ: キャッシュなど、文字列よりもスペースを節約します。

hset key field value //设置值
hget key field       //获取值

リスト:リンクされたリストに相当します。アプリケーションシナリオ: メッセージキューなど

LPUSH key  element1 element2 element3 ...   //左边插入元素,头插法
LPOP key                                    //移除并返回列表左侧的第一个元素,没有则返回nil

Set: HashSet に似ていますが、順序付けがなく、反復不可能です。適用シナリオ:共通の友人など

SADD key member1 member2 member3 ...  //向set中添加一个或多个元素
SREM key member1   //移除set中的指定元素

Zset: TreeSet に似ており、反復不可能で、重みパラメータがあり、これに従ってソートされます。応用シナリオ:ランキング一覧。

ZADD key score1 member1 score2 member2 score3 member3  //添加一个或多个元素到sorted set ,如果已经存在则更新其score值
ZREM key member1                                       //删除sorted set中的一个指定元素

3. Redis を使用する必要があるのはなぜですか?また、Redis が非常に高速であるのはなぜですか?

①メモリ動作が速い。1秒あたり110,000回の読み取りと80,000回の書き込み。
②トランザクションと永続化をサポートします。
③シングルスレッドでスレッド切り替えを回避します。Redis 6 ではマルチスレッドが導入されています。
④ IO多重化を利用して、複数の接続要求を単一スレッドで処理します。

4. キャッシュなだれ、キャッシュペネトレーション、キャッシュブレークダウン

キャッシュなだれ:キャッシュ内の大量のデータの有効期限が切れると、データベースにアクセスするために大量のリクエストが行われ、データベースに過剰な負荷がかかったり、ダウンタイムが発生したりします。または、redis がダウンしています。
解決策:
① キャッシュの有効期限の分布をより均等にします。
②高可用性クラスタをセットアップします。

キャッシュの侵入:キャッシュにもデータベースにも必要なデータがないため、リクエストが引き続き行われ、データベースに負荷がかかります。
解決策:
①キャッシュにnull値またはデフォルト値を設定します。
②ブルームフィルターを使用します。まずフィルターを使用してデータが存在するかどうかを確認し、存在する場合は検索を続けます。

キャッシュの内訳:特定のキーの有効期限が切れると、このキーにアクセスするリクエストが大量に発生し、データベースに過剰な負荷がかかります。
解決策:
① ミューテックス ロックを使用して 1 つのリクエストのみにアクセスを許可し、データをキャッシュに移動してから、残りのリクエストのリクエストにアクセスします。
②キャッシュを期限切れにしないように設定します。

5.Redis永続化メカニズム

RDB (デフォルト):メモリデータを一定期間内のスナップショット(ある瞬間のデータを記録する、写真を撮ることに相当)の形式でハードディスクに保存します。特定の時点でデータを一時ファイルに書き込み、最後に永続化されたファイルを置き換えます。

# 在 10秒之后,如果至少有 1 个 key 发生变化,Redis就会自动创建快照
save 10 1 

利点:大規模なデータセットをリカバリする場合、AOF よりも効率的です。
短所:安全ではない、データ損失。

AOF:書き込まれた各コマンドはログ ファイルに記録され (同じログ ファイルは置き換えられません)、redis の再起動により永続的なログ ファイルが復元されます。両方の永続性が有効になっている場合は、AOF が最初に復元されます。

# 开启 AOF 持久化
appendonly yes  

# 每次有数据修改发生时都会写入 AOF 文件,速度缓慢但是最安全
appendfsync always    

# 每秒钟同步一次,显示地将多个写命令同步到硬盘。AOF 默认使用的
appendfsync everysec  

# 让操作系统决定何时进行同步,速度最快
appendfsync no       

長所:安全で、データの損失はほとんどありません。
短所: AOF ファイルは RDB ファイルよりも大きく、回復速度が遅くなります。

6.redis の有効期限戦略

スケジュールされた削除:各キーにタイマーを作成する必要があり、時間が経過するとキーがクリアされるため、メモリに非常に優しいですが、有効期限を処理するために大量の CPU リソースを占有します。
遅延削除:キーの使用時に有効期限が切れているかどうかを判断し、期限が切れたら削除するため、CPU リソースを節約できますが、メモリには優しくありません。期限切れでクリアされていないキーが大量に存在する可能性があります。
定期的な削除:スケジュールされた削除と遅延削除の組み合わせ。期限切れのキーは定期的に抽出され、期限切れかどうかがチェックされます (デフォルトでは 1 秒あたり 10 回のクリアが実行され、毎回 5 つのテストが抽出されます)。期限切れの場合は、クリアされる。

# 1秒检查10次
hz 10 

# 一次抽取的个数,默认是5个
maxmemory-samples 5

7.redis の排除戦略

Redis メモリがいっぱいになると、メモリが削除され、いくつかのキーが削除されます。Redis 4.0 で追加された lfu 戦略。

# 默认的最大内存设置为1GB
maxmemory 1GB

①volatile-lru:有効期限が設定されているキーについては、lru アルゴリズム (最も最近使用されていないキー: 時間に基づく) を使用して削除します。
②allkeys-lru: lru アルゴリズムを使用してすべてのキーを削除します。
③volatile-lfu:有効期限が設定されているキーについては、lfu アルゴリズム (最も最近使用されていないもの: カウンタによる) を使用してキーを削除します。
④allkeys-lfu: lfu アルゴリズムを使用してすべてのキーを削除します。
⑤volatile-random:ランダム削除メカニズムを使用して、有効期限が設定されたすべてのキーを削除します。
⑥allkeys-random:ランダムな削除メカニズムを使用して、すべてのキーを削除します。
⑦volatile-ttl:有効期限が早いもの(残り生存時間が最も短いもの)を削除します。
⑧no-eviction (デフォルト):キーを削除しないでください。削除すると、操作でエラーが報告されます。

8. Redis の高可用性またはクラスタリングをセットアップする方法

① マスター/スレーブ レプリケーション: 1 つのマスター、1 つ以上のスレーブ、およびスレーブ ノードがマスター ノード上のデータを複製します。マスター ノードは書き込みを担当し、スレーブ ノードは読み取りを担当します。マスター ノードへの圧力をより適切に分散できますが、マスター ノードがダウンすると、一部のデータが同期されなくなります。
② センチネル モード (ポイント):マスター/スレーブ モードでもあり、センチネルは定期的にホストに問い合わせを行い、ホストが長時間応答しない場合、複数のセンチネルが新しいホストに投票します。可用性は向上しましたが、新しいマスター ノードの選択中はまだ機能しません。
③クラスタークラスターモード:マルチマスター、マルチスレーブ(通常はマスター3台、スレーブ3台)を採用し、ルールに従ってシャーディングを行い、各redisノードに異なるデータを格納することで、単一マシンストレージの問題を解決します。レプリケーションおよびフェイルオーバー機能も提供されます。設定はさらに面倒です。

9. redis は分散ロックを実装します

分散ロック:分散システム内のさまざまなプロセスを制御して共有リソースに共同でアクセスするロックの実装です。フラッシュ販売注文の発行、赤い封筒の取得などのビジネス シナリオではすべて、分散ロックの使用が必要です。Redis は分散ロックとして使用できます。
①コマンドsetnx+expireを別々に記述します。

setnx key value //新增一个key,key存在返回1,不存在不增加返回0
expire key 100  //key过100秒过期。单位是秒
问题:无法保证原子性,setnx锁了之后,然后出现问题,过期时间没有设置,那么锁就是永久的了(别的线程就永远获取不到锁了)

②setnx+valueの値が有効期限となります。

setnx key 过期时间  //把过期时间放到value,解决过期时间没有设置的问题,对比过期时间和当前时间就可以知道是否过期。
问题:取当前时间,分布式要求时间同步。

③Lua スクリプトを使用します (SETNX + EXPIRE の 2 つの命令を含む: アトミック性を確保)。

④setの拡張コマンド(SETキー値[EX秒][PXミリ秒][NX|XX])。

EX seconds:将键的过期时间设置为 seconds 秒。
PX milliseconds:将键的过期时间设置为 milliseconds 毫秒。
NX:只在键不存在的时候,才对键进行设置操作。SET key value NX 等同于 SETNX key value
XX:只在键已经存在的时候,才对键进行设置操作

set key value ex 10 nx  //key不存在才能新增,并且设置过期时间为10s。
问题:(1) 锁过期释放了,业务还没执行完。a获取锁,执行时间超过10秒,然后被b线程获取锁,导致代码执行顺序不一致。
	 (2)  锁被误删,因为(1),a没执行完释放锁,被b获取,然后a执行完,删除锁,然后b可能还没执行完。

⑤set ex px nx + ユニークなランダム値を確認して削除します。

把 value设置成一个随机数,删除的时候对比随机数,一致再删除。	
问题:还是存在业务没执行完,锁释放。

⑥オープンソースフレームワーク〜レディソン。

方案五还存在业务没执行完,锁释放问题。
Redisson:给获得锁的线程,开启一个定时守护线程,每隔一段时间检查锁是否还存在,存在则对锁的过期时间延长,防止锁过期提前释放。

⑦ マルチマシン分散ロック Redlock。5 つのサーバー上で 5 つのマスター ノードが実行されていると仮定します。

按顺序向5个master节点请求加锁
根据设置的超时时间来判断,是不是要跳过该master节点。锁过期时间是10ms,超时时间是20ms,那么就跳过。
如果大于等于3个节点(N/2+1)加锁成功,并且使用的时间小于锁的有效期,即可认定加锁成功啦。
如果获取锁失败,再所有主节点解锁,没获取到锁也会解锁,防止九年义务教育漏网之鱼。

詳細リンク

10. 分散ロックの特徴

相互排他性:常に 1 つのクライアントのみがロックを保持できる ロックの
タイムアウト解除:ロックが保持されている場合、リソースの不要な浪費やデッドロックを防ぐためにロックを解放できます
再入性:スレッドがロックを取得した場合、その後、リクエストは再度ロック可能
高パフォーマンスと高可用性:分散ロックの失敗を回避するために高可用性を確保しながら、ロックとロック解除は可能な限り低コストである必要があります セキュリティ: ロックは、
それを保持しているクライアントによってのみ削除できます。 、他のクライアントは削除できません

11.Redis アプリケーションのシナリオ

① キャッシュ
② データベース
③ ランキングリスト
④ カウンタ
⑤ メッセージキュー
⑥ 分散ロック
⑦ 共有セッション

おすすめ

転載: blog.csdn.net/twotwo22222/article/details/129005575