リディスとは何ですか?
Redis は現在最も人気のあるオープン ソース キャッシュ データベースであり、複数のデータ構造が含まれており、高い同時実行性と強いリクエスト圧力の下でリレーショナル データベースを支援するために使用されます。
Redis は、一般的に使用されるリレーショナル データベースとはまったく異なります。
- リレーショナル データベース (Mysql、Oracle など) の記憶領域はサーバーのハードディスクですが、redis はサーバーのメモリを使用するため、これも redis の長所と短所を生み出します。(クエリ速度は速いですが、ストレージ容量は小さいです)
- さらに、データのクエリ方法も異なり、従来のリレーショナル データベースは SQL コマンドを使用してクエリを実行しますが、redis はオペレーティング システムのコマンド ラインを使用して操作されます。
- リレーショナル データベースはテーブルとレコードの形式でデータを保存しますが、Redis ではすべてがデータ構造にデータを保存します。
- リレーショナル データベースには外部キーや主キーなどの関連フィールドがありますが、Redis にはそれらは存在しません。
Redis や memcached などの他のキャッシュ データベースも異なります。
https://blog.csdn.net/weixin_42295141/article/details/81380633の本文をここに引用します、兄貴のおかげで「仕方ないね～」
- ネットワーク IO モデルの観点から見ると、Memcached はマルチスレッドであり、リスニング スレッドとワーカー スレッドに分割されており、ロックの導入によりパフォーマンスが低下します。Redis はシングルスレッド IO 多重化モデルを使用して速度の利点を最大化し、よりシンプルなコンピューティング機能も提供します
- メモリ管理の観点から: Memcached は事前に割り当てられたメモリ プールを使用します。これにより、ある程度の領域の無駄が発生し、メモリにまだ多くの領域がある場合、新しいデータも削除される可能性がありますが、Redis は次の方法を使用します。データを保存するためにその場でメモリを適用するため、非一時データは削除されません Redis はキャッシュよりもストレージに適しています
- データの一貫性の観点: Memcached はそれを保証する cas コマンドを提供し、Redis は途中の操作によって中断されることなく一連のコマンドのアトミック性を保証できるトランザクション機能を提供します。
- ストレージ方法に関して: Memcached は単純なキーと値のストレージのみをサポートし、列挙はサポートせず、永続化やレプリケーションなどの機能もサポートしません。
Redisの利点?
- Redis はメモリに基づいて実行され、I/O の読み取りおよび書き込み速度が高速です。Redis は、1 秒あたり 100,000 以上の読み取りおよび書き込み頻度をサポートできます。
- 分散型、理論上無制限の拡張をサポート
- 豊富なデータ型 (文字列、ビットマップ、ハッシュ、リスト、セット、zset)
- トランザクションをサポートし、操作はアトミックです
- 持久化
Redisのデメリットは？
- サーバーがクラッシュすると、redis は実行を停止し、そこに保存されているデータが失われる可能性があります。(持続性なし)
- メモリの制限により、redis は大量のデータの記憶媒体として使用できません。
- Redis のマスター/スレーブ レプリケーションのパフォーマンスの問題: マスター/スレーブ レプリケーションの速度と接続の安定性を考慮すると、スレーブとマスターが同じ LAN 内にあることが最適です。
Redis は何のためにあるのでしょうか?
- seckill システムのリクエスト処理など、同時性の高いリクエスト インターセプト処理。
- セット データ型の SRANDMEMBER 関数などのデータ処理およびシーン アプリケーションでは、セットから 1 つ以上のキー (ユーザー ID など) をランダムに取得でき、これを宝くじ活動に使用できます。set データ型の SINTERCARD 関数は、2 つのセットの積部分を取得でき、公開の友人や共通のお気に入りアイテムなどを処理するために使用されます。もう 1 つの例は、ハッシュ データ型を使用してショッピング カートのデータを保存し、それを処理できることです。
Redis の基本用語:
- マスター (ホスト)/スレーブ (スレーブ)
a) ホスト: マスター サーバー、データ レプリケーションの対象となるサーバー
b) スレーブ: スレーブ サーバー、つまりデータ レプリケーションのスレーブとなるサーバー - 番兵
- クラスタ: 複数のサーバーで構成されるサーバー グループ。通常の選出 (ホストの選択) には、そのうち少なくとも 3 台のサーバーが必要です。また、マスター/スレーブ サーバー クラスターを構築する場合は、少なくとも 3 つのホストと 3 つのスレーブが必要です。
- 心拍検出
- キャッシュのブレークダウン、キャッシュなだれ、キャッシュのペネトレーション
a) キャッシュのブレークダウン: 多くの場合、同時実行性が高い状況で、期限切れまたは削除されたホットスポット データが Redis にある場合に、送信されたデータに関連するリクエストが多数存在する場合に発生します。時間が経つと、redis はリクエストをインターセプトする役割を果たすことができなくなり、大量のリクエストがデータベースに直接到達し、キャッシュの故障やデータベースのクラッシュにつながる可能性があります。解決策: setnx (存在しない場合は設定) を使用してミューテックスを設定します (以降の記事で詳しく説明します)。
b) キャッシュ雪崩: 大量のホット データが期限切れになるか、特定の瞬間に削除されると、大量のリクエストがこのキャッシュに到着します。 time データベースを使用すると、データベースに多大な負荷がかかります。解決策: キャッシュの無効化時間を分散するか、データベースアクセスをロックし、メッセージキューを使用します。
c) キャッシュの侵入: クエリされたデータ (キー) が Redis に見つからない場合、リクエストはデータベースに直接アクセスしますが、この時点では Redis キャッシュは役に立たないため、データベースに一定の負荷がかかります。解決策は、ブルーム フィルターを使用して、要求されたデータが存在するかどうかを判断することです。（以下の記事で詳しく解説しています）
Redis の基本?
- センチネルの仕組み
センチネル: モニターとも呼ばれ、センチネル (センチネル)、マスター (ホスト)、およびスレーブ (スレーブ) のステータスを監視するために使用されます。
監視方法は？
1) センチネル (センチネル) は、他のセンチネル (センチネル)、マスター (ホスト)、スレーブ (スレーブ) にメッセージ (ping コマンド) を定期的に送信し、相手のインスタンスが応答するのを待ちます。相手のサーバーが最後の有効な応答から遠く離れている
pong コマンドの時間差が、down-after-milliseced オプションで指定された値を超える場合、サーバーは主観的ダウン (SDOWN – 主観的ダウン) としてマークされます。
3) マスター (ホスト) が主観的オフラインとしてマークされている場合、サーバーを監視しているすべてのセンチネルは、サーバーが本当に主観的オフライン状態 (SDOWN – 主観的ダウン) に入ったかどうかを 1 秒に 1 回確認する必要があります。
4) 十分な数の監視員 (センチネル) が、ホストが主観的オフライン状態 (SDOWN – 主観的ダウン) にあることを発見したとき。次に、マスター (ホスト) は客観的ダウン (ODOWN - 客観的ダウン) としてマークされます。
5) ホストが主観的オフライン状態 (SDOWN - 客観的ダウン) であることを検出するのに十分なセンチネル (センチネル) がない場合、またはサーバーが有効なポン応答が返されると、サーバーの SDOWN ステータスは削除されます。
具体的な内容は追って更新していきますので、お楽しみに - マスタースレーブレプリケーション（同期）の
原理 マスターからスレーブへのデータバックアップのプロセス
具体的な内容は後日更新しますので、お楽しみに - Redis 永続性の原理
Redis 永続性は、サーバーがダウンしたときに母親が Redis データの損失を心配する必要がないように、ファイルの形式で Redis にデータを定期的に保存することです。永続化には、RDB と AOF という 2 つの具体的な方法があります。
具体的な内容は追って更新していきますので、お楽しみに
さらに多くのリンク
Redis のインストールhttps://blog.csdn.net/qq_31236027/article/details/121879741
Redis データ構造の概要https://blog.csdn.net/qq_31236027/article/details/121894713