魂からの質問: Map があるのに、なぜ Redis が必要なのでしょうか?

1. キャッシュでもあるのですが、マップは使えないのでしょうか？

1. Redis は数十ギガバイトのデータを保存できますが、Map は機能しますか?
2. Redis キャッシュはローカルに保存できますが、Map は機能しますか?
3. Redis は分散キャッシュとして使用できますが、Map は同じ JVM 内にのみキャッシュできます。
4. Redis は 1 秒あたり数百万の同時実行をサポートしていますが、Map は機能しますか?
5. Redis には有効期限メカニズムがありますが、Map にもありますか?
6. Redis には豊富な API があり、多くのアプリケーション シナリオをサポートしています。Map は大丈夫ですか?

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

1. コードがより明確になり、処理ロジックがよりシンプルになりました。
2. さまざまなロックの問題を考慮する必要がなく、ロックのロックと解放の操作がなく、デッドロックの可能性によって引き起こされるパフォーマンスの問題もありません。
3. CPU を消費するマルチスレッド切り替えはありません。
4. マルチコア CPU を利用することはできませんが、さらにいくつかの Redis インスタンスを開くことで改善できます。

3. Redis は本当にシングルスレッドですか?

1. Redis 6.0 より前はシングルスレッドでしたが、Redis 6.0 以降はマルチスレッドのサポートを開始しました。
2. Redis は内部で epoll ベースのマルチサービスを使用しており、複数の Redis サーバーをデプロイしてシングルスレッドの問題を解決することもできます。
3. Redis の主なパフォーマンスのボトルネックはメモリとネットワークです。
4. メモリは言うのは簡単で、メモリ スティックを追加するだけですが、ネットワークは大きな問題になるため、Redis6 メモリは言うのは簡単で、メモリ スティックを追加するだけです。
5. ネットワークが大きな問題となるため、Redis6.0 ではマルチスレッドの概念が導入され、
6. Redis 6.0では、ネットワークデータの読み書きやプロトコル解析などのネットワークIO処理にマルチスレッドが導入されていますが、コマンドを実行するコアモジュールは依然としてシングルスレッドであることに注意してください。

4 番目に、Redis の長所と短所

1. 利点

1. Redis は KV データベース、MySQL はリレーショナル データベースで、Redis の方が高速です。
2. Redis のデータ操作は主にメモリ内で行われ、MySQL は主にハードディスクにデータを保存し、Redis の方が高速です。
3. Redis は永続性 (RDB+AOF) もサポートしています。Redis は、Redis がクラッシュした場合のデータ損失を回避するために、メモリ内のデータをハードディスクに非同期的に永続化することをサポートしています。
4. Redis は非常に高いパフォーマンスを備えており、読み取り速度は 110,000 回/秒、書き込み速度は 81,000 回/秒です。
5. Redis には豊富なデータ型があり、KV キーと値のペアをサポートするだけでなく、リスト、セット、zset、ハッシュなどのデータ構造のストレージもサポートします。
6. Redis はデータ バックアップ、つまりマスター/スレーブ モードでのデータ バックアップをサポートしています。
7. Redis は単純なトランザクションをサポートしており、操作は原子性を満たします。
8. Redis は読み取りと書き込みの分離をサポートし、読み取りのプレッシャーを共有します。
9. Redis は、障害の自動転送を実現するセンチネル モードをサポートしています。
10. シングルスレッド操作により、頻繁なコンテキストの切り替えが回避されます。
11. 優れたパフォーマンスを備えたノンブロッキング I/O 多重化メカニズムを採用。

2. デメリット

1. データはメモリに保存されるため、データ損失が発生しやすくなります。
2. 記憶容量はメモリによって制限されており、一般的に使用されるデータは少量しか保存できません。
3. キャッシュとデータベースの二重書き込みの整合性の問題。
4. キャッシュに使用すると、メモリの侵入、キャッシュの破壊、キャッシュなだれなどの問題が発生しやすくなります。
5. 構成ファイルを変更した後、ハード ディスク内のデータをメモリに同期するために構成ファイルを再起動する必要がありますが、これには長い時間がかかり、データ同期時間中は Redis がサービスを提供できません。

5、Redis の一般的なビジネス シナリオ

1. Redis はメモリベースの nosql データベースであり、Redis シングル スレッドの読み取りおよび書き込み操作に影響を与えることなく、新しいスレッドの形式で永続化できます。
2. 最新N個のデータをリストから取得
3. トークンのように有効期限を設定する必要があるシナリオをシミュレートする
4. パブリッシュ・サブスクライブ・メッセージング・システム
5. タイマー、カウンター
6. キャッシュの高速化、分散セッション、リーダーボード、分散カウンター、分散ロック。
7. Redis は、トランザクション、永続性、LUA スクリプト、パブリッシュ/サブスクライブ、キャッシュ削除、ストリーミング テクノロジーおよびその他の機能をサポートします。

6 つの Redis の一般的なデータ型

1、紐

(1) 文字列の紹介

文字列は最も基本的なキーと値の構造であり、キーは一意の識別子、値は特定の値です。実際、値は文字列だけでなく数値 (整数または浮動小数点数) も含まれます。保持できる値は 512M です。

(2) 適用シナリオ

①キャッシュデータベースとして

Java 管理システムでは、ほとんどの場合、MySQL を使用してデータを保存し、Redis をキャッシュとして使用します。Redis は高い同時実行性をサポートする特性があるため、通常、読み取りと書き込みを高速化し、データベース サーバーへの負荷を軽減できます。 Redis にデータがない場合は、MySQL データベースをリクエストし、次回使用するために Redis にキャッシュします。

②カウンター

Redis 文字列にコマンドがありますINCR key。incr コマンドは値に対して自己インクリメント操作を実行します。たとえば、CSDN 記事の閲覧数とビデオの再生量は Redis を通じてカウントできます。各読み取り値は +1 になり、これらのデータは次のようになります。 MySQL データベースに非同期的に保存され、MySQL サーバーへの書き込み負荷が軽減されます。

③共有セッション

分散システムでは通常、ユーザーはリクエストのたびに異なるサーバーにアクセスするため、セッションが同期しない問題が発生しますが、現時点ではこの問題を解決するために Redis が一般的に使用され、セッションは Redis に保存されます。取り出してください。

④分散ロック

1. setnx キー値、ロック
2. delキー、ロックを解除します

(3) キー操作コマンド

（4）キー値を設定する

SET key value [NX | XX] [GET] [EX seconds | PX milliseconds | EXAT unix-time-seconds | PXAT unix-time-milliseconds | KEEPTTL]

1. EX 秒、有効期限を秒単位で設定します。
2. PX ミリ秒、有効期限をミリ秒単位で設定します
3. EXAT タイムスタンプ秒、有効期限、UNIX タイムスタンプを秒単位で設定します。
4. PXAT タイムスタンプ - ミリ秒、有効期限の設定、UNIX タイムスタンプ (ミリ秒)
5. NX、キーが存在しない場合にキー値を設定します
6. XX、キーが存在する場合はキーの値を設定します
7. KEEPTTL、設定する前に指定されたキーの有効期間を保持します。
8. GET、指定されたキーの元の値を返すか、キーが存在しない場合は nil を返します。

述べる：

コマンドでは大文字と小文字が区別されませんが、キーでは大文字と小文字が区別されます。

help @类型：現在のタイプに関連する操作コマンドを表示します。

SET コマンド オプションは SETNX、SETEX、PSETEX、GETSET を置き換えることができるため、Redis の将来のバージョンではこれらのコマンドが非推奨となり、最終的に削除される可能性があります。

(5) 複数のキー値を同時に設定する

(6) 指定した範囲内の値を取得する

getrange、setrange。

(7) 値の増減

1. INCR キー、数値をインクリメントします
2. INCRBY キーの増分、指定された値の増分を増加します
3. DECRキー、デクリメント値
4. DECRBY キーのデクリメント、指定された値のデクリメントを指定します

(8) 文字列の長さを取得し、内容を追加します

1. STRLEN キー、値の長さを取得します
2. APPEND key value，内容追加

2、リスト

(1) リストの紹介

List リストは、挿入順に並べ替えられた単純な文字列のリストであり、要素は先頭または末尾から List リストに追加できます。

リストの最大長は 2^32 - 1 です。これは、各リストが 40 億を超える要素をサポートすることを意味します。

主な機能はプッシュ/ポップであり、通常、スタック、キュー、メッセージ キュー、その他のシナリオで使用されます。

1. 左右どちらでも挿入・追加可能です。
2. キーが存在しない場合は、新しいリンク リストを作成します。
3. キーが存在する場合は、コンテンツを追加します。
4. 値がすべて削除されると、対応するキーも消えます。

最下層は二重リンク リストであり、操作の両端で高いパフォーマンスを発揮しますが、インデックス添字を使用して中間ノードを操作するパフォーマンスは低下します。

(2) 適用シナリオ

①メッセージキュー

メッセージ キューの使用lpush + rpopまたは実装により、Redis はブロック操作もサポートし、要素をポップするときにブロック コマンドを使用してブロック キューを実装します。rpush + lpop

② 重ねて使う

スタックを使用lpush+lpopまたは実装します。rpush+rpop

③記事一覧

(3) 共通コマンド

3、ハッシュ

(1) ハッシュの概要

ハッシュはキーと値のペア (キーと値) のコレクションであり、値もハッシュであり、 と同等ですMap<String,Map<Object,Object>>。

(2) 一般的なシナリオ

特殊なデータ構造のため、ハッシュは一般にストレージ Bean として使用され、String+JSON のデータ構造には特定のアプリケーション シナリオが格納されます。

(3) 共通コマンド

4、セット

(1) セット型の概要

Set タイプは順序付けされていない一意のキーと値のコレクションであり、その格納順序は挿入順序で格納されません。

セットには最大 2^32-1 個の要素を保存できます。この概念は基本的に数学の集合 (積集合、和集合、差分など) に似ています。そのため、集合型は集合内での追加、削除、変更、クエリをサポートするだけでなく、積集合、和集合、差分もサポートします。複数のセットの。

(2) 適用シナリオ

①同じ友達に公開される

友達の輪のシーンでは、いいねやコメントの機能について、交差することで同様の可視機能を実現できます。

② お互いの関心と共通の好み

③抽選機能

(3) 共通コマンド

5、セット

(1) Zsetタイプの紹介

Set 型と比較して、Zset 型 (順序付きセット型) には並べ替え属性スコア (ポイント値) が 1 つ多くあります。順序付きセット ZSet の場合、各記憶要素は 2 つの値に相当し、1 つは順序付けされた組み合わせです。そして 1 つはソート値です。

順序付きセットは、セットに重複したメンバーを含めることができない (スコアを繰り返すことができる) という特性を保持しますが、順序付きセット内の要素を並べ替えることができるという違いがあります。

zset k1 score1 v1 score2 v2

(2) 適用シナリオ

①リーダーボード

スコアを使用していいねの数を記録し、スコアに従って並べ替えてリーダーボードの機能を実現します。

② 遅延メッセージキュー

注文システム上、注文後 15 分以内に支払いを行わなければなりません。支払いが行われない場合、注文は自動的にキャンセルされます。

注文から 15 分後の時間をスコアとして使用し、注文を値として Redis に保存し、消費者がポーリングして消費し、消費量がスコア以上の場合、注文はキャンセルされます。

(3) Zset共通コマンド

6、ビットマップ

(1) ビットマップの概要

ビットマップ、つまりビットマップは連続したバイナリ配列（0と1）の連続であり、オフセット（offset）によって要素を配置することができます。BitMap では、最小単位のビットを使用して 0|1 を設定し、要素の値または状態を表し、時間計算量は O(1) です。

(2) 適用シナリオ

ビットはコンピューターの最小単位であるため、これをストレージとして使用するとスペースが節約され、大量のデータが使用されたり、バイナリ統計が使用されたりするシナリオに特に適しています。

①チェックイン統計

② ユーザーがログインしているかどうかを確認する

③継続的に勉強して打刻している人をカウントする

(3) BitMap共通コマンド

7、ビットフィールド

ビットフィールド コマンドを使用すると、複数のビットを一度に操作できます。一連の操作を実行し、応答配列を返します。この配列の要素は、パラメーター リスト内の対応する操作の実行結果です。

8、ハイパーログログ

(1) HyperLogLogの概要

Redis HyperLogLog は、Redis バージョン 2.8.9 の新しいデータ型です。「統計カーディナリティ」に使用されるデータ コレクション タイプです。カーディナリティ統計とは、コレクション内の固有の要素の数を指します。ただし、HyperLogLog は確率に基づく統計ルールであり、あまり正確ではなく、標準エラー率は 0.81% であることに注意してください。

つまり、HyperLogLog は不正確な重複排除カウントを提供します。

HyperLogLog の利点は、入力要素の数または量が非常に大きい場合でも、カーディナリティの計算に必要なメモリ スペースが常に固定され、小さいことです。

Redis では、各 HyperLogLog キーは、ほぼ 2^64 の異なる要素のカーディナリティーを計算するために 12 KB のメモリしか必要としません。要素の数が増加するにつれてより多くのメモリを消費する Set 型や Hash 型と比較して、HyperLogLog は非常にスペースを節約します。

(2) 適用シナリオ

100 万レベルの Web ページの UV カウント

(3) 共通コマンド

1. pfadd キー要素、要素を追加
2. pfcount キーは、指定された HyperLogLog のベースの推定値を返します。
3. pfmerge destkey sourcekey、複数の HyperLogLog を 1 つの HyperLogLog にマージします。

9、ジオ

(1) GEOの紹介

Redis GEO は Redis バージョン 3.2 の新しいデータ型で、主に地理的位置情報を保存し、保存された情報を操作するために使用されます。

私たちは日常生活において、「近くのレストラン」を検索したり、タクシー配車ソフトウェアでタクシーを呼んだりすることにますます依存していますが、これらすべては位置情報サービス (LBS) アプリケーションから切り離すことができません。LBS アプリケーションによってアクセスされるデータは、人や物に関連付けられた一連の経度と緯度の情報であり、隣接する緯度および経度の範囲をクエリできる場合、GEO は LBS サービス シナリオのアプリケーションに非常に適しています。

(2) 適用シナリオ

AutoNavi Maps や Didi Taxi などの測位ソフトウェア。

(3) 共通コマンド

10、ストリーム

(1) ストリームの概要

Redis Stream は、Redis バージョン 5.0 で新しく追加されたデータ型であり、メッセージ キュー用に特別に設計されたデータ型です。

Redis 5.0 Stream が登場する前は、メッセージ キューの実装には次のような独自の欠陥がありました。

• パブリッシュ/サブスクライブ モードでは、メッセージを永続化できない場合はメッセージを確実に保存できず、クライアントはオフラインで再接続されたクライアントの履歴メッセージを読み取ることができません。
• List がメッセージ キューを実装する方法では、繰り返し使用することはできません。メッセージは使用後に削除され、プロデューサーは独自にグローバルに一意な ID を実装する必要があります。

上記の問題を踏まえ、Redis 5.0 では、このバージョンの最も重要な機能でもある Stream 型を導入しました。これは、メッセージ キューを完全に実装するために使用されます。メッセージの永続化をサポートし、グローバルに一意な ID の自動生成をサポートし、 ACK 確認メッセージのモードをサポートし、消費をサポートします。グループ モードなどにより、メッセージ キューの安定性と信頼性が向上します。

(2) 適用シナリオ

メッセージキュー

(3) 共通コマンド

7. まとめ

Redis は 10 のデータ型をサポートするキーと値のストレージ システムであり、プログラム キャッシュとしてマップの代わりに Redis を使用する理由、Redis がシングルスレッドである理由、Redis の利点と欠点、および Redis の一般的なシナリオについてまとめています。入門。