なぜ、シングルスレッドのRedisを選択
シングルスレッドスレッドコンテキストの切り替えとロックの競合を削減します。
ネットワークIO IOモデルは、epollを登録識字イベント通知、同期非ブロッキングを使用して、多重化を使用しています。
シングルスレッド、マルチコアCPUの利点のRedisのを再生する方法
単一のサーバー上で実行されているRedisの複数のインスタンス。タスクセットのコマンドを使用し、各コアCPUのRedisのインスタンスとバインド
Redisのは、ロックが達成分散します
キーが存在しない場合は、キー値をsetnx、それが作成され、割り当てられています。成功したリターン1他の戻り0。有効期限を設定し、同時に：キー秒を期限切れ
また、NX EX-時間設定SETキー値EX 10086 NXとsetコマンドのオプションを使用することができます
キャッシュアバランシェ降伏キャッシュ、キャッシュの浸透
キャッシュ雪崩：KEY有効期限多数のデータベース内の圧力の急激な増加につながる可能性がキャッシュ無効化の瞬間に多く、その結果、あまりに濃厚です。
解決策：故障時間がランダムにこのようなシステムは、ウォームアップを開始したときに離散ある程度の有効期限を設定するなど、破壊しました。
キャッシュの内訳：特定のキャッシュKEYこの時点で多数の要求がキーを来ていない場合、有効期限は、キャッシュ層が流入としてデータベースクエリの多数の穴をドリルのようなものです、キャッシュにヒット
ソリューション：ダブルは、データベースからの道を確認してくださいデータがキャッシュに読み込まれます。ダブルチェック：クエリキャッシュの最初の層は一つだけ要求スレッドがデータベースを読むことを確認するために、クリティカルセクションに入ることができなかった後、重要なバッファゾーンを入力して再度試して、まだデータベースクエリにヒットしませんでした。
キャッシュの浸透：外部要求が存在しないシステムにデータを照会し続けるには、サービスではなく、データベースクエリから各試みをキャッシュにヒットすることはできません。
ソリューション：
- クエリの結果セットには、応答時間を犠牲にnull nullのキーキャッシュバッファ領域です。
- すべての違法なキーは、ビットマップ傍受によってビットマップにマッピングされています。「ブルームフィルタ」の原則
期限切れのRedisのキーを削除する方法
-
削除する期限切れのキーをチェックするために定期的にデフォルトのRedis、または不十分なメモリ機構がトリガされ、自動的に削除：イニシアティブを削除します
-
不活性は削除しますし、キーを読み書きする要求があった場合、キーの有効期限が切れるかどうかをチェックし、期限切れのを削除します
どのようにRedisの持続性
AOF
AOF（ファイルのみを追加）：Redisの各書き込みコマンドのために記録し、そのようなキー更新として10回、10の書かれた指示を記録します。それぞれが1秒に1回書き込み、または追加のアクションが発生した後に、設定することができます。長所：持続的な高域、異常なデータの損失少ないマシンダウン。短所：ファイルサイズ、比較的時間のかかる回復。
次のようにRedisのデフォルトRDBの永続性、永続性AOFは、同時に開くことができます
appendonly yes
appendfilename "appendonly.aof"
AOF書き換え
ファイルサイズが大きくなりすぎるとAOFが書き換えられます。アクションを書き換え前の鍵ペアの代わりに、複数のコマンドを記録するための鍵を記録するためのコマンドです。100回元のファイルが100点の指示を記録し、キー増分として、オリジナルの命令は新しい、AOF大幅圧縮されたファイルサイズにマージ書き換えます。
書き込む際の原則（コピーオンライト）の割り当ての使用を書き換え、直接元のファイルを操作しないでください。
RDB
RDB：スナップショットの永続性。特長は、データの全体量の点での時間を節約できます。利点：直接メモリと高速にロードされ、回復のスナップショットファイル。欠点は：データの総量が大きいため、周波数は、一般に、より低い持続性の設定です。最終更新データは、シャットダウン時間持続的な異常シャットダウンのために失われます。
RDBウェイ構成として
save 900 1 #在900s内如果有1条数据被写入，则产生一次快照。
save 300 10#在300s内如果有10条数据被写入，则产生一次快照
save 60 10000 #在60s内如果有10000条数据被写入，则产生一次快照
stop-writes-on-bgsave-error yes # 如果为yes则表示，当备份进程出错的时候， 主进程就停止进行接受新的写入操作，这样是为了保护持久化的数据一致性的问题。
bgsave
このコマンドは、永続的なスナップショットのbasaveによって手動でトリガすることができます。bgsave子プロセス、ライト・ライト・レプリケーションメカニズムをフォーク。仕事のメインプロセスをふさがないでください（saveコマンドを比較）。
AOFとRDBが開いAOF、と同時に使用することができ、RedisのはAOFデフォルトのログファイルキャッシュから再構築を開始します。
Redisのクラスタリングソリューション
- センチネル：センチネルモードは、主に高可用性を実現しています。Redisのは、ときにマスターインスタンス障害クラスタ全体の欠陥が機能しない原因となる、元のマスタ - スレーブ同期モードを解決します。Sentinelは、クラスタ内の選挙のマシンをオフラインで障害が新しいマスターノードを選出開始するため、このようなマスターとしてのRedisのクラスタの状態を、テスト、スタンドアロンのプロセスです。
- クラスタ：単一のホストメモリ容量に対応するために制限されています。Redisのハッシュ・クラスタの定義は、16,384のスロットがあり、各ノードは、いくつかのために責任があります。モジュロ16384のCRC16チェックサムによる各キーが配置されているスライスを決定します。
Redisのとデータベースの矛盾
あなたは、データベースの更新を更新するためにキャッシュをトリガする必要があります
あなたはキャッシュを削除し、データベースを更新すると、データベースから古いデータを読み取る一切キャッシュヒットが存在しないため、新しいリクエストが来る前に、データベースを更新することができます。あなたが最初のキャッシュデータベースの更新を削除した場合、データベース書き込みの失敗が成功した後に発生する可能性のあるキャッシュを削除します。これは、キャッシュが古いデータである原因となります。
- >データベース・ライター - 「再びキャッシュを削除キャッシュを削除するには：インターネット二重欠失戦略に循環。
利点は、データが更新される前に事前に確認することができます状態を作業のRedisですが、重要な問題：あなたはキャッシュされたを削除し、まだ存在していてもよい書き込みの後に失敗しました。根本的な解決には、書き込み後に失敗した削除時の再試行メカニズムを増やす、またはデータベースの更新をロールバックする必要があります。
メモリ戦略のうちのRedis
メモリを使用してRedisのメモリがmaxmemory構成されたサイズを超えて制圧戦略をトリガします。
- noeviction：ポリシーを削除しない、ダイレクトメモリは上限がエラーメッセージを返し達します
- allkeysランダム：キーのすべてのために、いくつかのランダムを削除
- allkeys-LRU：キーのすべてのために、最も使用優先順位を削除
- 有効期限を設定するための鍵は、いくつかのランダムを削除：揮発性ランダム
- 揮発性-TTL：有効期限を設定するためのキー、最速の有効期限は、キーの優先順位を削除します