分散開発(3)---Redisなら知っておきたい

分散開発では、Redis が依然として広く使用されており、その高性能と同時実行性が高く、数万の QPS を簡単にサポートできます。ここでは、簡単な Set および Get 操作だけを誰でも実行できるように、概要を示します。

1.Redisとは何ですか?

Redis は、データベース、キャッシュ、メッセージング ミドルウェアとして使用できるオープン ソース (BSD ライセンス) のインメモリ データ構造ストレージ システムです。文字列、ハッシュ、リスト、セット、範囲クエリを備えたソートされたセット、ビットマップ、ハイパーログログ、地理空間 (地理空間) インデックス半径クエリなど、さまざまなタイプのデータ構造をサポートします。Redis には、レプリケーション、LUA スクリプト (Lua スクリプティング)、LRU 駆動イベント (LRU エビクション)、トランザクション (トランザクション)、およびさまざまなレベルのディスク永続性 (永続性) が組み込まれており、Redis Sentinel (Sentinel) と自動パーティション (Cluster) を使用します。高可用性 (高可用性) を提供します。

それは 1 つの文に要約されます。Redis は、豊富なデータ型(文字列、ハッシュ、リスト、セット、ソートされたセットなど) をサポートするメモリベースの高性能KV データベースです。

 

2. Redis はなぜそれほど速いのですか?

まずは Alibaba Cloud on Redis QPS のテスト結果を見てみましょう

シングルスレッド Redis が 10w+ QPS をサポートできるのはなぜですか?
主に次の 3 つの側面があります。

• 純粋なメモリ操作
• シングルスレッド操作により、マルチスレッド状況でのコンテキスト切り替えの問題を回避
• ノンブロッキングI/O多重化機構を採用

ここでは、ノンブロッキング I/O 多重化メカニズムに焦点を当てます。

ノンブロッキング I/O 多重化

上図を参照すると、簡単に説明すると、Redis は Reactor モードに基づいたネットワーク通信を使用し、I/O 多重化プログラムを使用して複数のソケットを同時に監視し、それらをキューに入れ、ファイル イベント ディスパッチャーを使用します。順番に、キューからそれを取得し、別のイベント ハンドラーに転送します。

 

3. 一般的に使用されるデータ型と対応するシナリオ

タイプ	特徴	使用するシーン
文字列	最も基本的なタイプで、値は文字列または数値で、最大 512MB を保存できます。 一般的に使用されるコマンド: get、set、incr、decr、mget など。	キャッシュ、アトミックカウンターなど。
ハッシュ	文字列フィールドと文字列値の間のマップ、ハッシュはオブジェクトの保存に特に適しています	オブジェクトを使用してデータ (ユーザー情報など) を保存する
リスト	挿入順でソートされた、順序付けされた反復可能リスト、	単純なメッセージキュー
セット	順序付けされていない反復不可能なリスト	グローバル重複排除 積集合、和集合、差分などの演算により、共通優先度、全優先度、固有優先度を計算する機能を実現
ソートされたセット	各要素のスコアを持つ順序付けられたコレクション	リーダーボード アプリケーション、TOP N 操作を取得

 

4. Redis の永続化

Redis はさまざまなレベルの永続性を提供します。

1. RDB 永続化方式では、指定した時間間隔でデータのスナップショットを保存できます。
2. AOF 永続化メソッドは、サーバーに書き込まれるすべての操作を記録します。サーバーが再起動すると、これらのコマンドが再実行されて、元のデータが復元されます。AOF コマンドは、redis プロトコルを使用して、各書き込み操作をファイルの末尾に追加して保存します。 Redis は AOF も実行できます。AOF ファイルのサイズが大きくなりすぎないように、ファイルはバックグラウンドで書き換えられます。
3. サーバーの実行中にのみデータを存在させたい場合は、永続化メソッドを使用することもできません。
4. 2 つの永続化メソッドを同時に有効にすることもできます。この場合、一般に、RDB よりも AOF ファイルによって保存されたデータセットが保存されるため、redis が再起動されると、AOF ファイルが最初にロードされて元のデータが復元されます。データセットは完全である必要があります。

RDB と AOF の永続化メソッドの違いは次のとおりです。

RDB

RDB 永続化とは、メモリ内の Reid データベース レコードをディスク上の RDB に定期的にダンプして永続化することです。

利点:
1. RDB が RDB ファイルを保存するとき、親プロセスが行う必要があるのは子プロセスをフォークすることだけです。次の作業はすべて子プロセスによって行われます。親プロセスは他の IO 操作を実行する必要がありません。 RDB 永続化方式を最大限に活用できる Redis のパフォーマンスを最適化
2. AOF と比較して、大規模なデータセットを復元する場合、RDB 方式の方が高速になります。

欠点:
RDB は、5 分以上ごとに完全な保存を実行するなど、時間単位で保存されます。Redis が予期せずクラッシュした場合、数分間のデータが失われる可能性があります。

AOF

AOF永続化とは、Reidsの操作ログをファイルに追記することです。

利点:
1. AOF を使用すると、Redis データがより安全になります: さまざまな fsync 戦略を使用できます: fsync なし、毎秒 fsync、書き込みごとに fsync デフォルトの fsync 戦略を毎秒使用しても、Redis のパフォーマンスは依然として非常に優れています良好 良好 (fsync はバックグラウンド スレッドによって処理され、メイン スレッドはクライアントのリクエストを処理するために最善を尽くします)、障害が発生すると、最大 1 秒のデータが失われます
。 Redis は Rewrite AOF をバックグラウンドで自動的に保存できます

欠点:
同じデータセットの場合、通常、AOF ファイルの容量は RDB ファイルの容量よりも大きくなります。

 

5. 期限切れのキー処理戦略

Redis には、期限切れのキーをクリアする方法が 2 つあります: 通常の削除と遅延削除です。

定期的な削除戦略: デフォルトでは、Redis は 100 ミリ秒ごとに有効期限が設定されたキーをランダムに選択し、期限切れかどうかを確認し、期限切れの場合は削除します。(多くのキーが期限切れになり、削除されなくなります)
遅延削除戦略: キーを取得するとき、有効期限が設定されている場合、redis は最初にキーの有効期限が切れているかどうかを確認します。有効期限が切れた場合は、この時点で削除されます。(キーが要求されていない場合、キーは常に保存されます)

上記の分析によると、期限切れのキーの一部は省略およびクリアされ、Redis サーバーに常に存在します。Redis のメモリはどんどん増えていきます。その場合は、メモリ削除メカニズムを採用する必要があります。
redis.conf に設定の行があります

# maxmemory-policy volatile-lru

Redis は 8 つのメモリ削除メカニズムを提供します。

volatile-lru : 有効期限が設定されたデータ セット (server.db[i].expires) から最も最近使用されていないデータを選択し、有効期限が設定されたデータ セット (server.db[i) から
volatile-ttl : を削除します。 ].expires).expires) を使用して、有効期限が近づいているデータを選択し、
volatile-randomを削除します。 :
allkeys-lruを削除するために有効期限が設定されたデータ セット (server.db[i].expires) からデータをランダムに選択します。新しく書き込まれたデータを収容するにはメモリが十分ではありません。キー空間で、最も最近使用されていないキー (これが最もよく使用されます) を削除します。 allkeys-
random : データ セット (server.db[i]) からデータの削除をランダムに選択します。 .dict)。
no-eviction : データのエビクションを無効にします。デフォルト設定です。つまり、メモリが新しく書き込まれたデータを収容するのに十分でない場合、新しい書き込み操作はエラーを報告します。これは誰にも使用されるべきではありません。
バージョン 4.0 以降、次の 2 つのタイプが追加されました。
volatile-lfu : 有効期限を設定してデータセット (server.db[i].expires) から最も使用頻度の低いデータを選択し、allkeys
-lfu : メモリが不足している場合新しい書き込みに対応するのに十分なデータを入力するときは、キースペースで最も使用頻度の低いキーを削除します

 

6. Redis を使用するデメリットは何ですか

1. キャッシュとデータベースの二重書き込みの整合性の問題

一貫性は分散に関する一般的な問題であり、データベースとキャッシュが二重に書き込まれている場合、必然的に不整合が発生します。私たちが保証できるのは最終的な整合性のみです。したがって、強い整合性要件を持つデータはキャッシュできません。

ここで、更新戦略について簡単に説明します。まずデータベースを更新し、次にキャッシュを削除します。

次に、キャッシュの削除に失敗するという問題が発生する可能性があるため、メッセージ キューを使用して補償操作を実行できます。

 

2. キャッシュペネトレーションとキャッシュアバランシェの問題

キャッシュ侵入、つまり、キャッシュに存在しないデータ(ID が「-1」のデータなど) を意図的に要求し、その結果、すべての要求がデータベースに送信され、異常なデータベース接続が発生します。

解決策:
1. id<=0 の直接傍受など、インターフェイス層に検証を追加します;
2. ブルーム フィルターを使用して、一連の正当で有効なキーを内部的に維持します。

キャッシュ雪崩、つまり広い範囲で同時にキャッシュが期限切れになる現象が発生し、この時もリクエストの波が押し寄せ、その結果リクエストがすべてデータベースに送信され、データベースに過剰な負荷がかかり、異常が発生しました。接続。

解決策:
1. 集団的な無効化を避けるために、キャッシュの有効期限にランダムな値を追加します。
2. ミューテックスを使用します。