オリジナルリンク：https://blog.csdn.net/a745233700/article/details/85413179
A、Redisの有効期限ポリシーと同様にメモリ戦略のうち：
1、有効期限ポリシー：定期的に削除不活性+削除：
①定期的に削除：削除期限切れのがある場合、それは、有効期限が切れた場合のRedis 100ms毎にデフォルト設定キーの有効期限の時間のいくつかのランダムなサンプルについて、確認してください。これは、ランダムに選択されていることに注意してください。なぜそれがランダムにする必要がありますか？あなたはそれがキーの数十万人を救ったのRedisを考える場合は、すべてのキーを通じて100ms毎に、あなたはそれがCPUの負荷の多くをもたらすでしょう、有効期限を設定します。
②削除不活性：定期的に削除することは削除されていないキーの時間に戻って多くのにつながることができます。その後、削除された不活性を使用する必要があります。あなたは、キーの時間を取得し、Redisのは、あなたが有効期限と日付を設定した場合、そのキーをチェックし、それが削除されます。
2、定期的に+削除不活性の問題を削除します。
あなたがいない定期的に削除Deleteキーを行う場合には、不活性であるキーへの直接の要求は、ありません有効になりませんでした、削除。キーの数が多いメモリに蓄積期限切れこのとき、メモリが使い果たされるRedisのメモリブロックで、その結果、ますます高くなるのRedis。そして、それはメモリの除去メカニズムを使用する必要があります。
ない時限削除ポリシー？なぜ3、
定期的に削除は、キーを監視する責任があるとタイマーを使用し、自動的に削除される期限切れ。メモリのタイムリーなリリースが、非常に高いCPU使用率が、。大規模な同時要求では、CPU時間はあなたが要求を処理するのではなく、キーを削除して使用したいので、この戦略を使用していませんでした。
4、メモリ戦略からデータをRedisの：
問題：MySQLの、そこに2000ワットのデータは、データはRedisの中にホットデータであることを確実にする方法、唯一の20ワット格納されたデータのをRedisの？データセットのRedisのメモリサイズは、特定のサイズに上昇すると、彼らはデータ消去戦略を実行します。
①allkeys-LRU：すべての鍵空間で、最も最近使用されたキーを削除します。それは、この現在のプロジェクトでは、お勧めします。
②volatile-LRU：最も最近使用したキーを削除し、鍵空間の有効期限を設定します。これは、それが使用されているときにキャッシュが、また、永続的なストレージをした場合にのみ、Redisのが一般的です。お勧めできません
③allkeysランダム：鍵空間で、ランダムなキーを削除します。誰もそれを使用するべきではありません、あなたはランダム削除するには、少なくとも使用するキーを削除しないでください。
④volatileランダム：ランダムにキーを削除する鍵空間の有効期限を設定します。まだ、お勧めできません。
⑤volatile-TTL：期限切れキー排除することを削除、鍵空間の有効期限を設定します。お勧めできません。
⑥noeviction：除去されていない、新しい書き込みエラー。誰もそれを使用する必要があります。
PS：あなたは前提条件（前提条件）を満たしていない、キーの有効期限は設定しない場合、（削除しない）、その後揮発性-LRU、揮発性ランダムおよび揮発性-TTL戦略、およびnoevictionの行動を基本的に同じです。
二、レイズの永続的な方法：RDBとAOF
最初の永続的な方法：RDB
1、RDBは何か：
それは、ディスクを直接読み込むメモリからスナップショットファイルに復元されたときに、あるディスク（dump.rdbファイル）に書き込まれたデータセット、スナップショットスナップショットの指定した時間間隔メモリのスナップショット内。
2、永続的なデフォルト設定：
少なくとも一つのキーが変更された場合、900秒（15分）した後、ダンプメモリのスナップショットを900 1＃を保存します。
変更キー10、ダンプメモリのスナップショットが存在し、少なくとも場合は、300秒（5分）後に300 10＃を保存します。
少なくとも10,000個のキーが変化した場合、ダンプメモリのスナップショット、60秒（1分）の後に60万＃を保存します。
これは、1分以内万変更、または5分以内に10回、15分または1が変更に変更されます。
3、永続的な原則：
Redisのは、永続化するために子プロセスを別の（フォーク）を作成します永続的なプロセスであるためには、最初のデータで一時ファイルに書き込まれますその後、オーバー最後の良好な永続性ファイルを置き換えるために、一時的なファイルです。プロセス全体を通して、メイン処理は、性能の高いレベルを保証する任意のIO操作を行いません。
フォークの役割は、現在のプロセスと同じプロセスのコピーです。すべてのデータ（変数、環境変数、プログラムカウンタなど）と新しいプロセスの値は、元のプロセスと一致しているが、新しいプロセスであり、そして元プロセスの子プロセスとして。
4、利点：
あなたは、大規模なデータを復元する必要がある場合（1）、および、AOFの方法よりも効率的であるRDBの双方向データ復旧の整合性に非常に敏感ではありません。
（2）AOF機構に比べて、データセットが大きい場合、起動RDB効率が高くなります。
5、弱点：
（1）のRedisが誤って倒れそうならば、彼らは最後のスナップショットの後にすべての変更を失うことになる、一定の時間間隔でバックアップを作成します。
フォーク、データメモリがクローン化され（2）、約2倍の拡張必要が考慮されます。
第二の永続的な方法：AOF：
1、AOFは何ですか。
各書き込み操作を記録するログの形式では、Redisのは、（読みの操作が記録されていない）、我々はファイルのみを追加することができますが、Redisのの先頭から、ファイルを上書きすることはできません再構築データにファイルを読み込んで記録されたすべての書込みコマンドを実行しますログファイルの内容に基づいて、バックにリカバリデータを完了するために、前の書き込み命令後に実行されます上の他の言葉で、Redisのは、その後、再起動します。（Appendonly.aofファイル）
2、リライト機構AOFファイル：
（1）追加モードを使用して、AOFファイルは、ファイルがAOFファイルのサイズがしきい値設定を超えた場合に、このような状況が発生しないようにするために、新たなリライト機構大きくなるので、Redisのは、AOFファイルを開始します命令の唯一の最小セットは、データを復元するコマンドのBG rewriteaofを使用し、書換え動作AOF（AppendOnlyファイル）ファイルの非同期実行できる残しコンテンツ圧縮、。
（2）原則として書き換え：AOFファイルが成長し続け、大きすぎると、それは（一時ファイルを作成し、最後に名前を変更しても、最初の）ファイルを書き換えるための新しいプロセスをforkします、トラバースは、メモリ内の新しいプロセスのデータは、各レコードは持っています声明の中で設定します。ファイルAOF操作を書き換え、古いAOFファイルを読み取れませんが、新しいファイルAOFのメモリ書き換えコマンドでデータベース全体、そしてこのスナップショットの内容は似ています。
BGREWRITEAOFコマンドの実装では、Redisのサーバーは、子プロセスのAOFの新しいファイルが作成されますAOF書き換えバッファ管理し
、サーバで実行されるすべての書き込みコマンドのレコード間を。新しい作業AOFファイルを作成するプロセスが完了した後、サーバは、新旧両方のAOFファイルは、データベースの状態は一貫して保存したように、バッファのすべての内容を新しいAOFファイルの最後に追加されて書き換えます。最後に、サーバーは、ファイルAOF書き換え操作を完了するために、新しいAOFのAOFファイルと古いファイルを置き換えます。
（3）トリガタイミング：最後の書き換えとファイルサイズが64Mよりも大きい場合AOFファイルサイズが2倍にされたときのRedisが最後書き換えAOFサイズの時間を記録する、デフォルトの設定がトリガされます。
3、AOF持続性の設定：
（1）それぞれの変更の同期：appendfsyncは、常にデータの整合性、その永続的な、データの変更をすぐにディスクに記録されて同期すると、パフォーマンスが良く、各出現が悪いですけど。
（2）第二の同期：appendfsync everysec非同期動作、第二の記録、1秒以内のダウンタイムは、データが失われた場合。
（3）は同期されませんされていません：なし非同期のappendfsync
4、弱点：
データ（1）遅くRDBよりAOF RDBファイルの回復よりもはるかに大きなデータファイルの同じセットの観点インチ
RDBよりも遅い動作効率AOF（2）、毎秒よりよい同期戦略効率、同一の効率及びRDBに同期されていません。
注：永続的な方法の両方の二種類が、この場合、ファイル・データ・セットAOF通常の状況の下で格納された、元のデータを復元するために再起動優先負荷AOFファイルをRedisの場合RDBファイルが保存されるより完全なデータセットへ。
最適化の永続性メカニズムのRedis4.0：
Redis4.0（デフォルトでオフ、設定項目AOF使用-RDBプリアンブルによってオンにすることができる）RDBとAOF混合永続性をサポートするために始めました。
彼はRDB AOFファイルの先頭のコンテンツに直接書いた混合永続オープン、AOF書き換えた場合。この方法の利点は、あなたが迅速RDBとAOF、負荷の利点を組み合わせ、データの過度の損失を避けることができるということです。もちろん、欠点があり、圧縮形式AOF RDBの部分は、もはやAOF形式と可読性が悪いんですがあります。
三、Redisの取引：
本質的に、それはコマンドのセットがあり、一度に複数のコマンドを実行することができます。すべてのコマンドが順次直列化実行後、トランザクションで連載され、トランザクションの実行中に、トランザクションサーバは、他のクライアントのコマンド要求を実行するための変更を中断しないであろう、すなわち、コマンドは、他の中に挿入することができませんガッサーが許可され、それはすべてのトランザクションを命じて実行され、その後、唯一のコマンド要求の他のクライアントに対処します。すなわち、Aキュー、コマンドのシングル、シーケンシャル、排他的なシリーズを実行します。
1、一般的に使用されるコマンド：
（1）オープントランザクション：MULTI。MULTI実行した後、クライアントはサーバーに即時に実行されないコマンドの任意の番号を送信し続けることができますが、EXECコマンドが呼び出されたときに、バッファのキューに入れ、キュー内のすべてのコマンドが実行されます。
（2）トランザクションの実装：EXEC。
DISCARD：（3）は、トランザクションを放棄します。開いているトランザクションの後DISCARD、空のトランザクション・キューを呼び出して、執行部をあきらめることができます。
WATCH：モニターキー〜（4）。キーパラメータはRedisのWATCHのコマンドを監視しているように、Redisの変動は、検出することができます。トランザクションが実行される前に、これらのキーの変更が他のコマンドの場合は、トランザクション全体が中断されます。WATCHコマンドは、CAS（チェック・アンド・セット）機能を提供するために使用することができます。
（5）モニタ終了：UNWATCH。
2、Redisのトランザクション特性：
ときEXECコマンド以降のコマンドがまだ実行されますが、場合、コマンドは、Redisの同じトランザクションを失敗し、何のロールバックはありません：（1）非アトミック、ロールバックをサポートしていません。EXECコマンドでのみ一回限りのバッチプロセスは、バルク操作を実行することを保証します。
唯一の構文エラーや開発レベルにあるデータベース操作、誤ったタイプのである可能性があり、操作の失敗のRedisの上の理由は、本番環境に入らない問題で見つけることができるので、ロールバックする必要はありません。
Redisのは、インテリアデザインのシンプルで高性能、ありませんので、ロールバック機能を尊重しました。
そして、Redisのアプリケーションのシナリオは、信頼性の高いデータストレージおよび設計のための明確ではありませんが、高性能データ・アクセスの設計のために、シンプルかつ高パフォーマンスのための設計者は、原子、部分的に放棄しました。
②一貫性：
③別単独運転、すべてのコマンドは、シリアル化されたトランザクションが順次実行されます。トランザクションの実行中に、クライアントは、トランザクション要求に別のコマンドを送信し、実行コマンドシーケンスに挿入することはできません。分離レベルの概念がない、彼らは実際のトランザクションキューコマンドが提出していなかったの前に実行されることはありません。
④永続：Redisのは、持続性の特定のモードで動作している場合は、取引も永続的です。ときに追加専用モード、Redisのは、システムの機能を呼び出すことにより、この呼び出し内のすべてのディスク書き込みの業務におけるすべての書き込み操作を書き込みます。書き込みは、ダウンタイムなどによる停電、システムクラッシュ、中に発生した場合、データの他の一部が失われている間、しかし、その後の時間は、おそらくデータの一部だけが、ディスクに書き込まれます。
四、Redisのマスタースレーブのレプリケーション：
Redisのは、マスター・スレーブレプリケーションモードをサポートしています。原理は：自動的にスタンバイ・マシンのマスタ/よだれ機構に同期構成およびポリシーの更新に係るホストデータ、後に、スレーブは主に書き込むためにマスタ、マスターに同期データがない場合、スレーブは読取りほとんど。これは事実上、単一のマシンへの同時アクセスの数を減らすことができます。
図1に示すように、設定点：
（1）マスター値しないとライブラリから。
（2）ライブラリーの構成から：slaveofメインライブラリIPホスト・ポート・ライブラリー：
あなたはredis.conf設定ファイルを入力しない限り、（3）スレーブとマスターの切断後のたびに、あなたは、再接続する必要があります。
（4）閲覧Redisの設定情報：情報の複製
2、マスター・スレーブレプリケーションの原則：
（1）スレーブが正常にマスタ同期コマンドを送信する接続開始します。
受信したコマンドのデータセットに対するすべての変更を収集しながら、バックグラウンド・プロセスが終了した後、バックグラウンドプロセスに保存（2）マスタ同期スレーブへのコマンド、起動後、マスターは、完全なAに、スレーブにデータファイル全体を送信します完全に同期。
（3）合計量レプリケーション：ホストデータベースにスレーブサービスに及びメモリセーブロードされたデータファイルを受信した後。
（4）増分レプリケーション：マスターがコマンド奴隷、完全な同期を渡すために、すべての新しい変更を収集していきます。
（5）しかし限り、接続が再マスター、完全な同期（レプリケーションの合計量）が自動的に実行されるからです。
図3は、一般的に3つの戦略を使用しました。
2マスタスレーブ：マスターからA、2
（1）エントリポイントの問題？スレーブ1は、ゼロから始めるか、K4は、あなたがその前に123をコピーできるかどうか、から来たような？開始点からコピーするためのコピースレーブ2。A：最初からコピーします。
（2）スレーブが書き込み可能かどうか？あなたは、setコマンドを使用できますか？A：いいえ
何について（3）ホストが停止した後は？ホストマシンからスタンバイに残っているのですか？A：あなたがセンチネルモードを設定しない場合、それが待機しています。
（4）ホストが帰ってきた、ホストレコードを追加し、また、成功したマシンからコピーできますか？A：はい。
それらの（5）どのように1つの機械ダウン状況から？オリジナルの大きな力に合わせて、それについていくことができますか？A：再接続する必要があります。
B、トーチを渡します：
Aスレーブがマスタのスレーブであることができ、スレーブは、他のスレーブ接続し、同期要求を受信することができ、その後、次のチェーン内のマスタとしてスレーブは、効果的にマスターの筆圧を低減することができます。彼女がステアリングを変更しなければならなかった場合は、データは、ホストデータの再確立、最新のコピーする前にクリアされます。
C、マスターになるために：SLAVEOF誰。オリジナルのマスター後のハングアップし、このコマンドを実行するには、マスターを選択します。
4、センチネルモード（センチネル）：
障害が自動的にマスター・データベースに変換ライブラリからの投票数に応じた場合に自動バージョンの達人になるためには、背景には、ホストの障害かどうかを監視することができます。
以前のマスターの再起動が戻ってくる場合は、元のマスターがスレーブになるので、それは、二重のマスターの競合が発生することはありません。
設定手順：
中/ myredisカスタムディレクトリ名（1）新sentinel.confファイルは間違ってはなりません。
（2）設定Sentinelは、設定ファイルに記述された：センチネルモニターは（自分の名前から）データベース名を監視し127.0.0.1 6379 1
1上記の最後の数は、ホストがホストになるために投票数の後に、ホストを引き継ぐ者を確認するために軟膏票をぶら下がった状態を示しています。
（3）スタートセンチネル：Redisの-センチネル/myredis/sentinel.conf
図5に示すように、マスター・スレーブ複製欠点：すべての書き込み操作がマスター上で動作し、スレーブへの更新を同期する最初であるので、これスレーブ同期機へのマスターから遅れ、システムがビジーである、遅延の問題がありますマシンの数でより深刻な、奴隷の増加も、この問題を悪化させます。