分散型 Redis データベースのレビュー

導入

なぜこの記事を書くのですか?

ブロガーの「分散メッセージキューのレビューと詳細な説明」は皆様に好評を博しています。とても緊張しており、レビューと詳しい説明について別の記事を書こうと思っています。しかし、レビュー記事は面接の準備に関するものであることを指摘しておかなければなりません。実際の開発プロセスでは、現実的に、一歩ずつ進み、手抜きをしないことが求められます。

実際の開発でredisを使用する際に業務を書くプログラマーのほとんどがsetvalueとgetvalueの2つの操作しか知らないことを考えると、redisの全体的な理解が欠けていると言えます。ちょうどそのブロガーの同僚の 1 人が来週 Redis のトレーニングに参加する予定だったので、ブロガーはあえて Redis をトピックとして取り上げ、Redis の一般的な問題をまとめ、全員の知識の盲点を補うことを期待しています。

レビューポイントは？

この記事は以下の点に焦点を当てています

1. Redisを使用する理由

2. Redis を使用することの欠点は何ですか?

3. シングルスレッドの Redis が高速なのはなぜですか?

4. Redis のデータ型と各データ型の使用シナリオ

5. Redis の有効期限戦略とメモリ削除メカニズム

6. Redisとデータベース間の二重書き込みの一貫性の問題

7. キャッシュ侵入とキャッシュアバランシェの問題に対処する方法

8. Redisの同時競合問題を解決する方法

文章

1. Redisを使用する理由

分析: ブロガーは、プロジェクトで Redis を使用する場合、主にパフォーマンスと同時実行性の 2 つの観点から検討する必要があると考えます。もちろん、redis には分散ロックなどの他の機能もありますが、分散ロックと他の機能だけが必要な場合は、それらを置き換える他のミドルウェア (zookeper など) があります。 redisを使用する必要はありません。したがって、この質問には、主にパフォーマンスと同時実行性の 2 つの観点から答える必要があります。

答え：以下のように2つのポイントに分けて

1. パフォーマンス

話はそれますが、突然ですが、迅速な対応の基準についてお話ししたいと思います。実際、相互作用効果に応じて、この応答時間に固定の基準はありません。しかし、かつて誰かが私にこう言いました。「理想的には、ページジャンプは瞬時に解決される必要があり、ページ内の操作も瞬時に解決される必要があります。さらに、指をパチンと鳴らす以上の時間がかかる操作には、進行状況のプロンプトが表示され、いつでも中止またはキャンセルできるようにして、ユーザーに最高のエクスペリエンスを提供する必要があります。」

では、一瞬、一瞬、あるいは指をパチンと鳴らすのにはどれくらいの時間がかかるのでしょうか?

マハサンギカ・ヴィナヤによると

一つの瞬間は一つの考えであり、二十の考えは一つの瞬間であり、二十の瞬間は一つの指パッチンであり、二十の指パッチンは一つのルユであり、二十のルユは一つの瞬間であり、一日と一夜には三十の瞬間がある。

よく計算してみると、一瞬は 0.36 秒、一瞬は 0.018 秒、指をパチンと鳴らす時間は 7.2 秒になります。

2. 同時実行性

下の図に示すように、同時実行性が高い場合、すべてのリクエストがデータベースに直接アクセスし、データベースに接続例外が発生します。このとき、リクエストがデータベースに直接アクセスするのではなく、まず redis にアクセスできるように、redis を使用してバッファ操作を行う必要があります。

2. Redis を使用することの欠点は何ですか?

分析: 誰もが長い間 Redis を使用してきたため、この問題は理解されている必要があります。基本的に、Redis を使用するといくつかの問題が発生しますが、一般的な問題はいくつかあります。

答え: 主に4つの質問があります

(I) キャッシュとデータベースの二重書き込みの一貫性の問題

(II) キャッシュアバランシェ問題

キャッシュ故障問題

(IV) キャッシュの同時実行競合問題

個人的には、プロジェクトではこれら 4 つの問題がより一般的に発生すると思います。具体的な解決策については後述します。

3. シングルスレッドの Redis が高速なのはなぜですか?

分析: この質問は、実際には Redis の内部メカニズムの調査です。実際、ブロガーのインタビュー経験によると、Redis がシングルスレッドの動作モデルであることを知らない人が多いようです。したがって、この質問はまだ検討されるべきです。

回答：主に以下の3点

（I）純粋記憶操作

(ii) シングルスレッド操作により頻繁なコンテキスト切り替えを回避

（III）非ブロッキングI/O多重化機構の採用

余談: ここで、I/O 多重化メカニズムについて慎重に説明する必要があります。この用語は非常に一般的であるため、ほとんどの人がその意味を理解していないためです。ブロガーは例を挙げている。Xiao Qu は S 市に宅配店をオープンし、市内の宅配サービスを担当している。資金の制約のため、Xiaoqu は配達員のグループを雇いました。その後、シャオクさんは資金が足りず、配達用の車を買うのに足る金額しか残っていないことに気づいた。

ビジネスモデル1

顧客が荷物を送るたびに、Xiaoqu は宅配業者に荷物を預け、その後宅配業者が車で荷物を配達に向かいます。徐々に、Xiaoqu はこの動作モードに次のような問題があることを発見しました。

基本的に、何十人もの配達員が車両を奪い合うことに時間を費やしています。配達員のほとんどは暇です。車をつかんだ人は誰でも荷物を配達できます。
速達便が増えるにつれて、宅配便業者の数も増えていきました。 Xiao Qu さんは、宅配店がどんどん混雑していて、新しい宅配員を雇う方法がないことに気付きました。
宅配業者間の調整には時間がかかる

上記の欠点を踏まえて、Xiaoqu は失敗から学び、次のビジネスモデルを提案しました。

ビジネスモード2

Xiaoqu は配達人を 1 人だけ雇いました。その後、小区は顧客から送られた速達便を配達先ごとに印を付け、一か所に一つずつ置いていった。 ***、宅配業者は荷物を一つずつ受け取り、配達に行き、次の荷物を受取るために戻ってきます。

対比

上記の 2 つのビジネス方法を比較すると、2 番目の方法の方が効率的で優れていると思いませんか?上記の比喩では、

各宅配便 -----> 各スレッド
各エクスプレス ——————–> 各ソケット (I/O ストリーム)
配送先————–>ソケットの状態の違い
顧客速達依頼————–> クライアントからの依頼
Xiaoquのビジネスモデル————–>サーバー上で実行されるコード
自動車 ------------> CPUコアの数

そこで次のような結論が導かれる。

1. 動作モード 1 は従来の同時実行モデルであり、各 I/O ストリーム (express) は新しいスレッド (courier) によって管理されます。

2. 2番目の動作モードはI/O多重化です。各 I/O ストリームの状態 (各クーリエが配信されている場所) を追跡することで、複数の I/O ストリームを管理するスレッド (クーリエ) は 1 つだけです。

以下は、図に示すように、実際のRedisスレッドモデルとの類似点です。

上の写真を参考にしてください。簡単に言えばそうです。 redis クライアントが動作すると、さまざまなイベントタイプのソケットが生成されます。サーバー側には、それをキューに入れる I/O 多重化プログラムがあります。次に、ファイルイベントディスパッチャーはキューからファイルを順番に取得し、さまざまなイベントハンドラーに転送します。

この I/O 多重化メカニズムのために、redis は select、epoll、evport、kqueue などの多重化関数ライブラリも提供していることに注意してください。これについては自分で学習することができます。

4. Redis のデータ型と各データ型の使用シナリオ

分析: この質問は非常に基本的なものだと思われますか?実際私もそう思います。しかし、面接経験に基づくと、少なくとも 80% の人がこの質問に答えることができません。暗記するのではなく、プロジェクトで使用した後、類推して覚えることでより深い理解が得られるようにすることをお勧めします。基本的に、有能なプログラマーは 5 つのタイプすべてを使用します。

答え: 合計5つ

1. 文字列

実のところ、これについては特に言うことはありません。最も一般的な設定/取得操作では、値は文字列または数値になります。一般的に、いくつかの複雑なカウント関数をキャッシュします。

(II) ハッシュ

ここで、value は構造化されたオブジェクトを格納し、その中で特定のフィールドを操作する方が便利です。ブロガーがシングルサインオンを行う場合、このデータ構造を使用してユーザー情報を保存し、cookieId をキーとして使用し、キャッシュの有効期限を 30 分に設定することで、セッションのような効果を非常にうまくシミュレートできます。

（III）リスト

リストデータ構造を使用すると、単純なメッセージキュー機能を実行できます。もう 1 つは、lrange コマンドを使用して、優れたパフォーマンスと優れたユーザーエクスペリエンスを備えた Redis ベースのページングを実行できることです。

(IV) セット

セットスタックは、繰り返されない値のコレクションであるためです。したがって、グローバル重複排除機能を実行できます。重複排除に JVM 独自のセットを使用しないのはなぜですか?当社のシステムは一般的にクラスターで展開されるため、JVM に付属するセットを使用するのは面倒です。グローバル重複排除を行うためだけにパブリックサービスを開始するのは面倒すぎます。

さらに、積、和、差などの演算を使用することで、共通の好み、すべての好み、独自の好み、その他の関数を計算することができます。

(V) ソートされた集合

ソートされたセットには追加の重みパラメータスコアがあり、セット内の要素はスコアに従ってソートできます。アプリケーションのランキングや TOP N 操作に使用できます。さらに、ソート済みセットが遅延タスクに使用できることを指摘している別の記事「分散遅延タスクソリューションの分析」を参照してください。 *** 1 つのアプリケーションは範囲検索を行うことです。

5. Redis の有効期限戦略とメモリ削除メカニズム

分析: この質問は実はかなり重要です。 Redis が効果的に使用されているかどうかを表示できます。たとえば、Redis が 5G のデータしか保存できないのに、10G を書き込むと、5G のデータが削除されます。削除するにはどうすればいいですか?この質問について考えたことはありますか?また、データの有効期限が設定されていますが、有効期限が来てもメモリ使用量は依然として高いままです。その理由について考えたことはありますか？

答え：

Redis は、定期的な削除 + 遅延削除の戦略を採用しています。

スケジュールされた削除戦略を使用しないのはなぜですか?

スケジュールされた削除: タイマーを使用してキーを監視し、有効期限が切れると自動的に削除します。メモリは時間内に解放されますが、CPU リソースを大量に消費します。同時リクエストが大量にある場合、CPU はキーを削除するのではなく、リクエストの処理に時間を費やす必要があるため、この戦略は採用されません。

スケジュールされた削除 + 遅延削除はどのように機能しますか?

定期的な削除。 Redis は、期限切れのキーがあるかどうかをデフォルトで 100 ミリ秒ごとにチェックします。期限切れのキーがある場合は削除されます。 Redis は 100 ミリ秒ごとにすべてのキーをチェックするのではなく、ランダムに選択して検査することに注意してください (すべてのキーが 100 ミリ秒ごとにチェックされると、Redis が停止します)。したがって、定期的な削除戦略のみを採用した場合、多くのキーが時間どおりに削除されません。

そこで、遅延削除が役に立ちます。つまり、キーを取得すると、有効期限が設定されていれば、Redis はキーの有効期限が切れているかどうかを確認します。期限が切れた場合は、この時点で削除されます。

定期削除＋遅延削除で他に問題はないでしょうか？

いいえ、定期削除時にキーが削除されない場合は、そうではありません。次に、キーをすぐに要求しなかったため、遅延削除は有効になりませんでした。このように、Redis のメモリはどんどん高くなっていきます。次に、メモリ削除メカニズムを採用する必要があります。

redis.confには設定行があります

# 最大メモリポリシー揮発性LRU

この設定は、メモリ削除戦略を設定するためのものです（え、今まで一度も設定したことないの？反省してください）

1) noeviction: 新しく書き込まれたデータを収容するのに十分なメモリがない場合、新しい書き込み操作はエラーを報告します。誰も使ってないと思います。

2) allkeys-lru: 新しく書き込まれたデータを格納するためのメモリが不足している場合は、キー空間内で最も最近使用されていないキーを削除します。この方法を使用することが推奨されており、現在のプロジェクトでもこの方法が使用されています。

3) allkeys-random: 新しく書き込まれたデータを格納するためのメモリが不足している場合、キーはキー空間からランダムに削除されます。誰もそれを使うべきではありません。最も使用頻度の低いキーを削除しない場合は、ランダムに削除してください。

4) 揮発性 LRU: 新しく書き込まれたデータを格納するためのメモリが不足している場合、有効期限のあるキー空間内で最も最近使用されていないキーを削除します。この状況は通常、Redis がキャッシュと永続ストレージの両方として使用される場合に発生します。推奨されません

5) 揮発性ランダム: 新しく書き込まれたデータを収容するのに十分なメモリがない場合、有効期限が設定されたキーがキー空間からランダムに削除されます。それでもまだ推奨されない

6) 揮発性 TTL: 新しく書き込まれたデータを格納するためのメモリが不足している場合、有効期限が設定されているキー空間内で、有効期限が早いキーが最初に削除されます。推奨されません

ps: キーに有効期限が設定されておらず、前提条件が満たされていない場合、volatile-lru、volatile-random、および volatile-ttl ポリシーの動作は基本的に noeviction と同じになります。

6. Redisとデータベース間の二重書き込みの一貫性の問題

分析: 一貫性の問題は一般的な分散問題であり、さらに結果的一貫性と強い一貫性に分けることができます。データベースとキャッシュが二重に書き込まれると、必然的に不整合が生じます。この質問に答えるには、まず前提を理解する必要があります。つまり、データの一貫性が強く求められる場合、キャッシュを配置することはできません。私たちにできるのは、最終的な一貫性を確保することだけです。さらに、私たちが実装したソリューションは、不整合の可能性を根本的に減らすことはできますが、完全に回避することはできません。したがって、強い一貫性要件を持つデータはキャッシュできません。

回答: 「分散データベースとキャッシュのデュアル書き込み一貫性スキームの分析」では詳細な分析が示されていますので、ここでは簡単に説明します。まず、正しい更新戦略を採用し、最初にデータベースを更新してから、キャッシュを削除します。第二に、キャッシュ削除に失敗する問題が発生する可能性があるため、メッセージキューを使用するなどの補償策を提供することができる。

7. キャッシュ侵入とキャッシュアバランシェの問題に対処する方法

分析: 正直に言うと、これら 2 つの問題は、一般的な中小規模の従来のソフトウェア企業が遭遇する可能性は低いです。大規模な同時プロジェクトがある場合、トラフィックは数百万程度になります。これら二つの問題について深く検討する必要があります。

回答: 下記の通り

キャッシュ侵入とは、ハッカーがキャッシュに存在しないデータを故意に要求し、すべての要求がデータベースに送信され、データベース接続に異常が発生することを意味します。

解決：

（１）ミューテックスロックを使用する。キャッシュが無効な場合は、まずロックを取得してからデータベースを要求します。ロックが取得できない場合は、しばらくスリープしてから再試行してください

（２）非同期更新戦略を採用し、キーに値があるかどうかに関係なく直接戻ります。キャッシュの有効期限が値に保持されます。キャッシュの有効期限が切れると、スレッドが非同期的に開始され、データベースを読み取ってキャッシュを更新します。キャッシュの事前加熱（プロジェクトを開始する前にキャッシュをロードすること）が必要です。

（３）ブルームフィルタを使用して一連の有効なキーを内部的に維持するなど、リクエストが有効かどうかを迅速に判断できる傍受メカニズムを提供する。リクエストに含まれるキーが合法かつ有効かどうかを素早く判断します。違法な場合は、直接返品してください。

キャッシュアバランシェとは、キャッシュの広い範囲が同時に障害を起こすことを意味します。このとき、別のリクエストの波が来て、リクエストがすべてデータベースにプッシュされ、データベース接続異常が発生します。

解決：

（１）キャッシュの有効期限にランダムな値を追加して、一括有効期限切れを回避します。

(ii) ミューテックスロックを使用しますが、このソリューションではスループットが大幅に低下します。

(iii) ダブルバッファリングキャッシュ A とキャッシュ B の 2 つのキャッシュがあります。キャッシュ A の有効期限は 20 分ですが、キャッシュ B の有効期限は設定されていません。キャッシュウォーミング操作を自分で実行します。次に、次の点に分解します。

キャッシュAからデータベースを読み取り、存在する場合は直接返します。
II A にはデータがないため、B から直接データを読み取り、直接戻り、非同期的に更新スレッドを開始します。
III 更新スレッドはキャッシュ A とキャッシュ B を同時に更新します。

8. Redisの同時競合キー問題を解決する方法

分析: 問題は、複数のサブシステムが同時にキーを設定することです。この時、何に注意すべきでしょうか？これについて考えたことはありますか？なお、ブロガーは事前に Baidu で検索したところ、回答では基本的に Redis トランザクションメカニズムの使用が推奨されていることがわかった。ブロガーは、Redis トランザクションメカニズムの使用を推奨していません。当社の本番環境は基本的に Redis クラスター環境であるため、データシャーディング操作が実行されます。トランザクションに複数のキー操作が含まれる場合、これらの複数のキーは必ずしも同じ redis サーバーに保存されるわけではありません。したがって、Redis のトランザクションメカニズムは非常に役に立たないです。

回答: 下記の通り

（１）キー操作の場合は、命令は不要

この場合、分散ロックを用意し、全員がそのロックを取得しようとします。ロックを取得したら、set 操作を実行するだけです。比較的簡単です。

（２）キーを操作する場合は、

key1 があると仮定します。システム A は key1 を valueA に設定する必要があり、システム B は key1 を valueB に設定する必要があり、システム C は key1 を valueC に設定する必要があります。

key1 の値は valueA–>valueB–>valueC の順に変化することが予想されます。この場合、データベースにデータを書き込むときにタイムスタンプを保存する必要があります。タイムスタンプが次の通りであると仮定する

システムA キー1 {valueA 3:00}  
システム B キー 1 {valueB 3:05}  
システム C キー 1 {値 C 3:10}

したがって、システム B が最初にロックを取得し、key1 を {valueB 3:05} に設定するとします。次に、システム A はロックを取得し、その valueA のタイムスタンプがキャッシュ内のタイムスタンプよりも早いことを検出したため、設定操作を実行しません。等々。

キューを使用してセットメソッドをシリアルアクセスに変換するなどの他の方法も可能です。つまり、柔軟であることです。

要約する

この記事では、Redis の一般的な問題をまとめます。それらのほとんどは、ブロガーが仕事で遭遇した質問と、過去に他の人にインタビューしたときによく聞く質問です。また、直前に詰め込むことはお勧めできません。実際に経験豊富なエンジニアに会ったら、彼らの質問で簡単に混乱させられるかもしれません。 ***、皆さんが何か得られることを願っています。

シリーズレビュー