分散コンピューティングに Redis を使用するのはなぜですか?

ビジネスアプリケーションを作成するプログラマーの多くは、実際の開発で Redis を使用する際に Set Value と Get Value の 2 つの操作の使用方法しか知らず、Redis の全体的な理解が不足しています。ここでは、誰もが知らない Redis の問題の概要を示します。

1. Redis を使用する理由

プロジェクトで Redis を使用する場合、パフォーマンスと同時実行性の 2 つの主要な考慮事項があります。分散ロックなどの他の機能だけが必要な場合は、代わりに Zookpeer などのミドルウェアがあり、Redis を使用する必要はありません。

パフォーマンス：

下の図に示すように、実行に特に長い時間がかかり、結果が頻繁に変更されない SQL に遭遇した場合は、実行結果をキャッシュに入れることが特に適しています。このようにして、後続のリクエストはキャッシュから読み取られ、リクエストに迅速に応答できるようになります。

特にフラッシュセールシステムでは、ほぼ全員が同時にクリックして注文をしています。 。 。同じ操作、つまりデータベースからデータを照会する操作が実行されます。

応答時間には固定された標準はなく、相互作用効果によって異なります。理想的には、ページジャンプは瞬時に解決され、ページ内の操作は瞬時に解決される必要があります。

同時：

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

Redisの使用に関する一般的な問題

• キャッシュとデータベースの二重書き込みの一貫性の問題
• キャッシュアバランシェ問題
• キャッシュ故障問題
• キャッシュの同時実行競合問題

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

この問題は、Redis の内部メカニズムの調査です。 Redis がシングルスレッドの動作モデルであることを知らない人はたくさんいます。

その理由は主に以下の3点です。

• 純粋なメモリ操作
• シングルスレッド操作により頻繁なコンテキスト切り替えを回避
• ノンブロッキングI/O多重化メカニズムを採用

I/O 多重化メカニズムについて詳しく説明します。たとえば、Xiaoming は A 市にファーストフード レストランをオープンし、市内のファーストフード サービスを担当しています。財政的な制約のため、シャオミンは配達員のグループを雇いました。その後、シャオ・クゥさんは資金が足りず、急行便を配達するために車しか買えないことに気づいた。

ビジネスモデル1

顧客が注文するたびに、シャオミンは配達員に注文を監視するよう依頼し、誰かを派遣して配達してもらいます。徐々に、Xiaoqu はこの動作モードに次のような問題があることを発見しました。

すべての時間は車をつかむことに費やされます。ほとんどの配達員は暇なので、車を拾ってからしか商品を配達できません。

• 注文数が増えるにつれて、配達員の数も増えていきました。シャオミンは、宅配店がどんどん混雑してきて、新しい配達員を雇うことができないことに気づきました。
• 配達員間の調整には時間がかかります。
• 上記の欠点を考慮して、シャオミンは自分の失敗から学び、2番目のビジネスモデルを提案しました。

ビジネスモード2

シャオミンは配達員を1人だけ雇っています。顧客が注文すると、シャオミンは配達場所をマークし、それらを 1 か所にまとめます。最後に、配達員に荷物を一つずつ配達してもらい、配達が終わったら次の荷物を回収しに戻ってもらいます。上記の 2 つの操作方法を比較すると、2 番目の方法の方が効率的であることは明らかです。

上記の例えでは、

• 各配達員→各スレッド
• 各注文 → 各ソケット（I/Oフロー）
• 注文の配送場所→ソケットの状態が異なる
• 顧客からの食品配達依頼 → クライアントからの依頼
• Mingquのビジネスモデル → サーバー上で実行されるコード
• 車1台 → CPUコア数

したがって、次のような結論に達します。

• 最初の動作モードは従来の並行モデルであり、各 I/O フロー (注文) は新しいスレッド (配達員) によって管理されます。
• 2 番目の動作モードは I/O 多重化です。各 I/O ストリームの状態 (各配達員の配達場所) を追跡することで、複数の I/O ストリームを管理するスレッド (配達員) は 1 つだけです。

次の図は、実際の Redis スレッド モデルに類似しています。

Redis クライアントが動作している場合、さまざまなイベント タイプのソケットが生成されます。サーバー側には、それをキューに入れる I/O 多重化プログラムがあります。次に、ファイル イベント ディスパッチャーはキューからファイルを順番に取得し、さまざまなイベント ハンドラーに転送します。

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

有能なプログラマーは 5 つのタイプすべてを使用します。

弦

最も一般的な設定/取得操作。値は文字列または数値になります。一般的に、いくつかの複雑なカウント関数をキャッシュします。

ハッシュ

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

リスト

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

セット

Set は繰り返されない値のコレクションであるためです。したがって、グローバル重複排除機能を実行できます。当社のシステムは通常、クラスターで展開されるため、JVM に付属するセットを使用するのは面倒です。さらに、積、和、差などの演算を使用することで、共通の好み、すべての好み、独自の好み、その他の関数を計算することができます。

ソートセット

Sorted Set には追加の重みパラメータ Score があり、セット内の要素はスコアに従ってソートできます。アプリケーションのランキングや TOP N 操作に使用できます。ソート セットは遅延タスクに使用できます。

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

ここからRedisが効果的に使われているかどうかが分かります。たとえば、Redis が 5G のデータしか保存できないのに、10G を書き込むと、5G のデータが削除されます。削除するにはどうすればいいですか?この質問について考えたことはありますか?

正解: Redis は定期削除 + 遅延削除の戦略を採用しています。

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

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

定期削除+遅延削除はどのように機能するか

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

定期削除＋遅延削除を使用すれば他に問題は発生しないでしょうか？

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

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

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

この構成はメモリ削除戦略用です:

• noeviction: 新しく書き込まれたデータを収容するのに十分なメモリがない場合、新しい書き込み操作でエラーが報告されます。
• allkeys-lru: 新しく書き込まれたデータを収容するのに十分なメモリがない場合は、キー空間内で最も最近使用されていないキーを削除します。 (推奨、現在プロジェクトで使用中) (最近使用したアルゴリズム)
• allkeys-random: 新しく書き込まれたデータを収容するのに十分なメモリがない場合、キーはキー空間からランダムに削除されます。 (誰も使用しないはずなので、最も使用頻度の低いキーを削除せずにランダムに削除してください)
• volatile-lru: 新しく書き込まれたデータを収容するのに十分なメモリがない場合、有効期限が設定されたキー空間内で最も最近使用されていないキーを削除します。この状況は通常、Redis がキャッシュと永続ストレージの両方として使用される場合に発生します。 (非推奨)
• 揮発性ランダム: 新しく書き込まれたデータを収容するのに十分なメモリがない場合、有効期限が設定されたキーがキー空間からランダムに削除されます。 (それでもお勧めできません)
• volatile-ttl: 新しく書き込まれたデータを格納するためのメモリが不足している場合、有効期限が設定されたキー空間では、有効期限が早いキーが最初に削除されます。 (非推奨)

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

一貫性の問題は、結果的一貫性と強い一貫性に分けることもできます。データベースとキャッシュが二重に書き込まれると、必然的に不整合が生じます。前提として、データに対して強い一貫性の要件がある場合、キャッシュを配置することはできません。私たちにできるのは、最終的な一貫性を確保することだけです。

さらに、私たちが実装したソリューションは、不整合の可能性を根本的に減らすことしかできません。したがって、強い一貫性要件を持つデータはキャッシュに配置することはできません。まず、正しい更新戦略を採用し、最初にデータベースを更新してから、キャッシュを削除します。第二に、キャッシュ削除に失敗する問題が発生する可能性があるため、メッセージキューを使用するなどの補償策を提供することができる。

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

これら 2 つの問題は、中小規模の従来のソフトウェア企業ではほとんど発生しません。数百万のトラフィックを伴う大規模な同時プロジェクトがある場合、これら 2 つの問題を深く考慮する必要があります。キャッシュ侵入とは、ハッカーがキャッシュに存在しないデータを故意に要求し、すべての要求がデータベースに送信され、データベース接続に異常が発生することを意味します。

キャッシュ侵入ソリューション:

• ミューテックス ロックを使用すると、キャッシュが無効な場合に、まずロックを取得してからデータベースを要求します。ロックが取得されない場合は、しばらくスリープしてから再試行してください。
• 非同期更新戦略を採用すると、キーに値があるかどうかに関係なく、キーが直接返されます。 Value 値はキャッシュの有効期限を維持します。キャッシュの有効期限が切れると、スレッドが非同期的に開始され、データベースを読み取ってキャッシュを更新します。キャッシュの事前加熱（プロジェクトを開始する前にキャッシュをロードすること）が必要です。
• リクエストが有効かどうかを迅速に判断できるインターセプト メカニズムを提供します。たとえば、ブルーム フィルターを使用して、一連の有効なキーを内部的に維持します。リクエストに含まれるキーが合法かつ有効かどうかを素早く判断します。違法な場合は、直接返品してください。

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

キャッシュアバランチソリューション:

• 一括有効期限切れを回避するために、キャッシュ有効期限にランダムな値を追加します。
• ミューテックス ロックを使用しますが、このソリューションのスループットは大幅に低下します。
• ダブルバッファリング。 CacheA と CacheB という 2 つのキャッシュがあります。キャッシュ A の有効期限は 20 分ですが、キャッシュ B には有効期限がありません。キャッシュウォーミング操作を自分で実行します。
• 次に、次の点に分解します。キャッシュ A からデータベースを読み取り、データがある場合は直接返します。 A にデータがない場合、B から直接データを読み取り、直接戻り、更新スレッドを非同期的に開始します。これにより、キャッシュ A とキャッシュ B が同時に更新されます。

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

基本的に問題は、複数のサブシステムが同時にキーを設定することです。この時、何に注意すべきでしょうか？基本的に誰もが 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 のタイムスタンプがキャッシュ内のタイムスタンプよりも早いことを検出し、設定操作を実行しません。キューを使用してセット メソッドをシリアル アクセスに変換するなどの他の方法も可能です。

8. まとめ

Redis は、Sina、Alibaba、Tencent、Baidu、Meituan、Xiaomi などの国内大手企業で採用されています。Redis を学ぶ際には、Redis クライアント、高度な Redis 機能、Redis の永続性と開発および運用における一般的な問題に関する議論、Redis レプリケーションの原則と最適化戦略、Redis 分散ソリューションなどが特に重要です。