あなたはRedisのキャッシング技術を使用している場合、それは確かにRedisの高い並行性を確保、機械カドガンのRedisのを使用する方法を検討する必要がありますが、直接ハング死亡していない自分の将来を確保するためのRedisを作成する方法があります。
Redisの高い同時実行：主なアーキテクチャ、マスターマルチスレーブは、一般的には、実際には、多くのプロジェクトは、スタンドアローン十QPSの何千もの、データを書き込むために使用される単一のマスタから十分である、複数のインスタンスからデータを照会するために使用以上からは、提供することができますQPS 100,000。
Redisの高い同時実行、また、大量のデータに対応することが必要である：マスターマルチスレーブを、各インスタンスは、メモリ10GのRedisの主の量として完全なデータを、受け入れる、実際には、あなたはほとんどのデータ量だだけで10グラムを収容することができます。データの量は、あなたは大きなキャッシュに対応したい場合は、グラム数十、あるいはグラムの数百、あるいは数トンに達し、その後はRedisのクラスタを必要とし、Redisのクラスタに続く、第二月あたり数十万人を提供することができます同時読み取りと書き込み。
Redisの可用性：あなたはそれを見張りと相まって、実際には、インフラストラクチャの展開からショットを呼び出す場合は、達成することができ、ダウンタイムのいずれかのインスタンスは、自動切換えになります。
次の詳細。
どのようにQPS + 10万人以上の独立した読みの読み取りおよび書き込み要求によって運ば.redis？
高い同時実行のシステム全体との関係1.redis高い同時
Rredisが高い同時実行に従事高い同時データベースは、実装が比較的煩雑であるなど、いくつかの操作だけでなく、トランザクションを必要とするので、それがあるので、それは、直接データベースになるように少数のリクエストをキャッシュの下部を向上させる必要があります非常に高い同時実行を行うのは難しいです。
システム全体のために良い行うにはRedisの同時並行はまだ十分ではありませんが、全体のRedis大きなキャッシュアーキテクチャとして、アーキテクチャは、非常に重要な部分である、高い同時実行をサポートしています。
高い同時実行システム、ミドルウェア最初のキャッシュを実現するために、キャッシュシステムは、高い並列性を支えることができなければならない、そして全体的に良好なキャッシュ・アーキテクチャ（マルチレベルキャッシュ、キャッシュホットスポット）の後、順番に真に高い同時実行からサポートすること。
2.redisは、高並行性のボトルネックをサポートすることはできません
Redisのは、高並行性のボトルネックに関係なくどのようにマシンのパフォーマンスの良い、上限がある場合でも、一つだけのRedisことを意味し、主に単一問題でサポートすることはできません。
高い同時実行性をサポートする方法3
スタンドアローン同時Redisのをサポートすることができないことは、別の読み取りおよび書き込みであってもよいが高い同時実行をサポートするために、高すぎます。キャッシュの場合、そこに一般的に高い同時サポート読み取りは、ある要求が比較的小さい書き込み、それはスキーマから分離メインに基づいて読み取ることができます。
マスタデータにデータを受信した後、上記スレーブに同期させることができ、データを書き込むために使用される（メイン）機械、スレーブ複数の（からの）にデータを読み取るマスタの設定、スレーブは、複数のマシンように構成されていてもよいです私たちは、全体の同時実行性を向上させることができます。
マスタースレーブアーキテクチャのための二つの.redisの複製とマスターの永続的セキュリティへの影響
レプリケーションの原理を1.redis
スレーブ複数のマスターノードは、上記マスタノードにデータを書き込むために、以下の書き込み操作を吊りノードおよびすべてのノードのデータであることを保証するために、上述したスレーブノードのすべてにデータを同期させるために、非同期操作により、マスタ後に終了しました一貫性のあります。
コア力学の複製を2.redis
（1）Redisのは、非同期スレーブノードにデータをコピーしますが、redis2.8、スレーブノードは定期的に複製当たり、その数を確認し始めました。
（2）マスタノードは、複数のスレーブノードを構成することができます。
（3）スレーブノードは、他のスレーブノードに接続されてもよいです。
コピーを行うとき（4）スレーブノード点は、マスタノードの正常な動作をブロックしていません。
（5）その動作をブロックしていないコピー時間をやってスレーブノードを、それがサービスを提供するために、古いデータを使用します。コピーが完了したときただし、古いデータを削除する必要があり、新しいデータがロードされ、この時間は外となりますサービスの提供を停止します。
（6）主に横方向の拡張のために使用されるスレーブノードを、別個の読み出しを行い、書き込み、スレーブノード拡張のスループットを向上させることができます。
マスタースレーブアーキテクチャの3.master永続的なセキュリティへの影響
このマスター・スレーブ・アーキテクチャなら、それは持続性にマスターノードを開く必要があります。このような場合にはマスターが一度ダウンした場合、再起動のデータが空になった後、他のスレーブノードがデータを複製する場合は、その後、マスターデータは、失われてしまうので、我々はそれがだろう、マスターノードのホットバックアップとしてスレーブノードの使用はお勧めしません。すべてのノード上のデータが失われたように、空にコピー。
、様々なコールドバックアップのバックアップファイルを作成するには、全マシンが壊れている防ぐために、RDBのデータのバックアップにも状況を失います。
三.redisマスタースレーブレプリケーション原則、HTTP、ディスクの無いコピー、期限切れのキー処理
1.マスター・スレーブ原理をコピーします。
①それがマスターノードにPSYNCコマンドを送信するときに、スレーブノードを起動します。
スレーブノードがマスターノード、スレーブコピーデータの一部のみ削除に、マスタノードが再接続される場合②、それは最初のマスターノードに接続されている場合、それは、完全な再同期化をトリガします。
③完全再同期の開始時刻を、マスターはRDBは、スナップショットファイルを生成開始するバックグラウンドスレッドを開始するだけでなく、すべてのクライアントからのコマンドを記述し、それらのメモリに新しいキャッシュを受けました。
④masterノードRDBがスレーブノードにファイルを生成し、スレーブは、ローカルディスクに書き込まれ、その後、ディスクからメモリにロードされます。そして、メモリキャッシュのマスターノードがスレーブノードにコマンドを送信します書き込み、スレーブノードは、いくつかのデータを同期します。
マスターノードと⑤slaveノードは、ネットワークの障害を切断した場合、それは自動的に再接続します。
⑥master再接続するために、複数のスレーブノードがある場合、単に操作保存RDBを開始し、スレーブノードを持つすべてのデータサービス。
2.マスタースレーブレプリケーションHTTP
HTTPのサポートredis2.8最初から。マスタースレーブのレプリケーションプロセスは、ネットワークが突然切断した場合は、その後、最後の場所をコピーではなく、最初からコピーよりも、複製し続けることができます。
原理：
マスターノードはバックログ、マスターとスレーブがバックログに保存されているオフセット、オフセットレプリカとマスターIDを保持するメモリ内に作成されます。マスターとスレーブのネットワーク接続が切断した場合、スレーブ・マスターは、オフセットレプリカの最後のコピーから開始していきます。オフセットが見つからない場合は、それは完全な再同期操作を実行します。
3.ディスクのないコピーを
コピーのディスクレスは再びマスターファイルRDBダイレクト・メモリを作成することで、その後はないデータを保存するための独自のローカルディスクには、スレーブに送信されました。
設定モード
設定REPL-ディスクレス同期とREPL-ディスクレス同期遅延パラメータ。
REPL-ディスクレス同期：このパラメータは何のディスクのコピーを確保しないように行われます。
REPL-ディスクレス同期遅延：スレーブノードの複数の新しい接続を待つことができるように、このパラメータは、時間の長さを示し、その後、開始コピーを待ちます。
4.有効期限キー処理
スレーブは、キーの有効期限が切れるだけの期限切れのマスターキーを待ちません。
期限切れのマスターキー、またはキーのうち、マスタがスレーブをシミュレートするためにdelコマンドを送信する場合は、スレーブを受けた後、キーを削除します。
完全な流れの深さの分析は、再び4 .redis複製のプロセスと原則を実行しています
1.完全なプロセスをコピーします。
①slaveノードが開始されると、唯一のマスターノードおよびホストのIPを含め、情報のマスターノードを保持しているが、データの複製はまだ始まっていません。マスターノードとホストはslaveOf内部redis.conf IPドキュメントに配置されています。
②slave内部ノードが見つかった場合は、新しいマスターノードがネットワークソケット接続を確立するだけで、マスタノードのように、コピーに接続するために、場合秒ごとにチェックするためにcronジョブを持っています。
③slaveノードがマスターノードにpingコマンドを送信します。
④マスターがrequirepassを設定した場合、スレーブノードは、パスワードマスター認証過去を送信しなければなりませんが認証されています。
フルボリュームコピーを行う初めて⑤masterノードは、スレーブノードにすべてのデータを送信します。
持続⑥masterノードは、スレーブノードへの非同期レプリケーションを書き込みコマンドをドロップします。
2.データの同期メカニズム
これは、マスタが、複製の総量が行われた場合に接続された第1のスレーブを指します。
①masterとスレーブを維持するオフセット
オフセットを蓄積していき、それ自体をマスター、スレーブ、オフセット自体に蓄積し続けます。すべての第2のスレーブは、マスタは、各スレーブのオフセットを保持する一方で彼らは、マスターにオフセットを報告しました。
この特定のコピーは主にマスタとスレーブの状況を知るためにデータ、互いの間で一貫性のないデータをオフセット彼らの知っている必要があり、完全な量で使用しないこと
②backlog
メモリ内のバックログがあるマスターノードは、デフォルトでは1Mが大きいです。
スレーブノードにマスターノードがデータを複製する際に、データがバックログに同期されます。
受注残高は、主にインクリメンタルボリュームの複製複製のフルタイムの中断を作るために使用されます。
③master実行ID
Redisのは、情報サーバを介して、マスタ実行IDを表示することができます。
使用：スレーブは独自のマスターに応じて配置されています。
なぜ+ IPをホストしてい：マスターを見つけるためのホスト+ IPの使用が飛んでいないため、マスターノードの再起動やデータが変更された場合、スレーブは異なるマスター実行IDに基づいて区別されるべきで、全額一度行われるID異なるニーズを実行しますコピー。
あなたは実行IDの再起動のRedisを変更する必要がない場合は、Redisの-CLIデバッグreloadコマンドを使用することができます。
3.プロセスとメカニズムの全額をコピーします。
①master実行bgsave、RDBは、ローカルファイルを生成します。
②masterノードは、スレーブノードRDBにスナップショットファイルを送信し、RDBの時間あなたは60秒（REPL-タイムアウト）を超えるファイルをコピーする場合、スレーブノードは、タスクが失敗したコピーされます、あなたはパラメータを調整することができます。
③ギガビット・イーサネット・マシンの場合は、一般的に第二100Mあたりに、6Gのファイル転送が60秒を超える可能性があります。
RDBファイルを生成するときに④masterノードた後、それがメモリにキャッシュ書き込みコマンドにすべての新しいなり、スレーブノードは、スレーブノードをコピーし、その後、書き込みコマンドをRDBファイルを保存します。
⑤このような[クライアント出力バッファ制限スレーブ256メガバイト64メガバイト60]のように表示するクライアント出力バッファ制限スレーブパラメータは、複製中に発現され、インメモリキャッシュ複製を停止、その後、256メガバイトを超える64M以上、または1時間を消費し続けること、コピーに失敗しました。
サービスを提供するために、古いデータに基づいて、その過程で、⑥slaveノードRDBファイルを受け取った後、あなたのデータを空にして、あなたの記憶にRDBファイルをリロードします。
⑦スレーブノードがAOFを開いた場合、それはすぐにBRREWRITEAOF、再AOF、RDB生成、ネットワークを介してRDBのコピーを実行され、データが古い奴隷、書き換えAOF奴隷、非常に時間がかかり、場合4G〜6G間のデータ複製の量をクリーンアップ、時間の総量が十二時五十八分半のコピーを費やしている可能性があります。
メカニズム4.増分レプリケーション・プロセス
①複製プロセス、マスターとスレーブネットワーク接続の全額が壊れている場合は、スレーブ・マスターは、レプリケーションをトリガーするサプリメントを再接続します。
データの部分的な損失の独自バックログから直接②masterをスレーブノードに送信されます。
③masterデータはオフセットにPSYNCスレーブに係る伝送バックログから取得されます。
5.ハートビート
マスタとスレーブが相互にハートビートメッセージを送信します。
10秒ごとに送信されるデフォルトのマスター、デフォルトで毎秒回送信スレーブノード。
6.非同期レプリケーション
各マスタは今、内部書込データを書き込むコマンドを受信し、非同期スレーブノードを送信するようにした後
どのように私は建築から99.99パーセントの.redis 5つの主要な高可用性を行うことができますか？
1. 99.99％の可用性とは何ですか？
高可用性（英語：高可用性、HAと略す）、専門用語は、システムに代わって、その機能を実行するためのシステムの中断能力のない可用性の程度を意味します。これは、システム設計時の基準の一つです。システムの様々なコンポーネントを構成する高可用性システムと比較して、より長時間実行してもよいです。
高可用性は、通常、システムの耐障害性を向上させることによって達成されます。システムは、多くの場合、各ケースの特定の状況の詳細な分析は、高可用性を必要としていると考えられる方法を定義します。
そのメトリックは、システムの損傷に応じて、時間を使用することができず、システムの総動作時間に比べて、時間の動作状態であることを操作することによって復元することができません。式は次のとおりです。
（可用性）、MTBF（平均故障間隔）、MDT（平均時修復します）
オンラインシステムやミッションクリティカルなシステムは、典型的には、5〜9標準（99.999％）に達するために彼らの可用性を必要とします。
| 可用性 | ダウンタイムで |
|---|---|
| 99.9999％ | 32秒 |
| 99.999％ | 5分15秒 |
| 99.99% | 52分34秒 |
| 99.9% | 8小时46分 |
| 99% | 3天15小时36分 |
2.redis不可用
redis不可以包含了单实例的不可用，主从架构的不可用。
不可用的情况：
①主从架构的master节点挂了，如果master节点挂了那么缓存数据无法再写入，而且slave里面的数据也无法过期，这样就导致了不可用。
②如果是单实例，那么可能因为其他原因导致redis进程死了。或者部署redis的机器坏了。
不可用的后果 ：首先缓存不可用了，那么请求就会直接走数据库，如果涌入大量请求超过了数据库的承载能力，那么数据库就挂掉了，这时候如果不能及时处理好缓存问题，那么由于请求过多，数据库重启之后很快就又会挂掉，直接导致整个系统不可用。
3.如何实现高可用
①保证每个redis都有备份。
②保证在当前redis出故障之后，可以很快切换到备份redis上面去。
为了解决这个问题，引入下面的哨兵机制。
六.redis哨兵架构的相关基础知识的讲解
1.什么是哨兵？
哨兵(Sentinal)是redis集群架构当中非常重要的一个组件，它主要有一下功能：
①集群监控 ，负责监控redis master和slave进程是否正常工作。
②消息通知，如果某个redis实例有故障，那么哨兵负责发送消息作为报警通知给管理员。
③故障转移，如果master挂掉了，会自动转移到slave上。
④配置中心，如果故障发生了，通知client客户端连接到新的master上面去。
2.哨兵的核心知识
①哨兵本身是分布式的，需要作为一个集群去运行，个哨兵协同工作。
②故障转移时，判断一个master宕机了，需要大部分哨兵同意才行。
③即使部分哨兵挂掉了，哨兵集群还是能正常工作的。
④哨兵至少需要3个实例，来保证自己的健壮性。
⑤哨兵+redis主从结构，是无法保证数据零丢失的，只会保证redis集群的高可用。
⑥对应哨兵+redis主从这种架构，再使用之前，要做重复的测试和演练。
3.为什么哨兵集群部署2个节点无法正常工作？
哨兵集群必须部署2个以上的节点。如果集群仅仅部署了2个哨兵实例，那么quorum=1(执行故障转移需要同意的哨兵个数)。
如图，如果这时候master1宕机了，哨兵1和哨兵2中只要有一个认为master1宕机了就可以进行故障转移，同时哨兵1和哨兵2会选举出一个哨兵来执行故障转移。
同时这个时候需要majority(也就是所有集群中超过一半哨兵的数量)，2个哨兵那么majority就是2，也就说需要至少2个哨兵还运行着，才可以进行故障转移。
但是如果整个master和哨兵1同时宕机了，那么就只剩一个哨兵了，这个时候就没有majority来运行执行故障转移了，虽然两外一台机器还有一个哨兵，但是1无法大于1，也就是无法保证半数以上，因此故障转移不会执行。
4.经典的3节点哨兵集群
Configuration: quorum = 2，majority=2
如果M1所在机器宕机了，那么三个哨兵还剩下2个，S2和S3可以一致认为master宕机，然后选举出一个来执行故障转移
同时3个哨兵的majority是2，所以还剩下的2个哨兵运行着，就可以允许执行故障转移
七.redis哨兵主备切换的数据丢失问题：异步复制、集群脑裂
1.两种数据丢失的场景
①异步复制导致的数据丢失
因为从master到slave的数据复制过程是异步的，可能有部分数据还没来得及复制到slave上面去，这时候master就宕机了，那么这部分数据就丢失了。
②集群脑裂导致的数据丢失
什么是脑裂：脑裂，也就是说，某个master所在机器突然脱离了正常的网络，跟其他slave机器不能连接，但是实际上master还运行着。
此时哨兵可能就会认为master宕机了，然后开启选举，将其他slave切换成了master。
这个时候，集群里就会有两个master，也就是所谓的脑裂。
此时虽然某个slave被切换成了master，但是可能client还没来得及切换到新的master，还继续写向旧master的数据可能也丢失了。
因此旧master再次恢复的时候，会被作为一个slave挂到新的master上去，自己的数据会清空，重新从新的master复制数据
2.解决异步复制的脑裂导致的数据丢失
要解决这个问题，就需要配置两个参数：
min-slaves-to-write 1 和 min-slaves-max-lag ：
表示 要求至少有一个slave 在进行数据的复制和同步的延迟不能超过10秒。
如果一旦所有的slave数据同步和复制的延迟都超过了10秒，那么这个时候，master就会在接受任何请求了。
①减少异步复制的数据丢失
有了min-slaves-max-lag这个配置，就可以确保说，一旦slave复制数据和ack延时太长，就认为可能master宕机后损失的数据太多了，那么就拒绝写请求，这样可以把master宕机时由于部分数据未同步到slave导致的数据丢失降低的可控范围内。
②减少脑裂的数据丢失
如果一个master出现了脑裂，跟其他slave丢了连接，那么上面两个配置可以确保说，如果不能继续给指定数量的slave发送数据，而且slave超过10秒没有给自己ack消息，那么就直接拒绝客户端的写请求。
这样脑裂后的旧master就不会接受client的新数据，也就避免了数据丢失。
上面的配置就确保了，如果跟任何一个slave丢了连接，在10秒后发现没有slave给自己ack，那么就拒绝新的写请求。
因此在脑裂场景下，最多就丢失10秒的数据
八.redis哨兵的多个核心底层原理的深入解析（包含slave选举算法）
1.sdown和odown两种状态
sdown是主观宕机，就一个哨兵如果自己觉得一个master宕机了，那么就是主观宕机。
odown是客观宕机，如果quorum数量的哨兵都觉得一个master宕机了，那么就是客观宕机
sdown达成的条件很简单，如果一个哨兵ping一个master，超过了is-master-down-after-milliseconds指定的毫秒数之后，就主观认为master宕机。
sdown到odown转换的条件很简单，如果一个哨兵在指定时间内，收到了quorum指定数量的其他哨兵也认为那个master是sdown了，那么就认为是odown了，客观认为master宕机。
2.哨兵集群的字段发现机制
①哨兵相互之间的发现，是通过redis的pub/sub系统实现的，每个哨兵都会往 __sentinel__:hello 这个channel里面发送一个消息，这时候其他的哨兵都可以消费这个消息，并感知其他哨兵的存在。
②每个两秒钟，每个哨兵都会往自己监控的某个master+slave对应的 __sentinel__:hello channel里面发送一个消息，内容是自己的host、ip和run id还有对这个master的监控配置。
③每个哨兵也会去监听自己监控的每个master+slave对应的 __sentinel__:hello channel，r然后去感知到同样在监听这个master+slave的其他哨兵的存在。
④每个哨兵还会根据其他哨兵交换对master的监控配置，互相进行监控配置的同步。
3.slave配置的自我纠正
哨兵会负责自动纠正slave的一些配置，比如slave如果要成为潜在的master候选人，哨兵会确保slave在复制现有master数据；如果slave连接到了一个错误的master上，比如故障转移之后，那么哨兵会确保他们连接到正确的master上来。
4.选举算法
如果一个master被认为odown了，而且majority数量的哨兵都允许了主备切换，那么某个哨兵就会执行主备切换，此时首先要选举一个slave出来。选举会考虑到一下情况：
①slave跟master断开连接的时长
②slave的优先级
③slave复制数据的offset
④slave的run id
首先，如果一个slave跟master断开连接已经超过了 down-after-millisecondes 的10倍，外加master宕机的时长，那么slave就被认为不适合选举为master了。
即：断开连接时间 > (down-after-milliseconds * 10 + milliseconds_since_master_is_in_SDOWN_state).
对应剩下的slave按照如下规定排序：
①首先，按照slave的优先级进行排序，slave priority越低，优先级就越高。
②如果优先级相同，那么就看replica offset，那个slave复制了越多的数据，offset越靠后，优先级就越高。
③如果上面都想同，那就选择run id最小的那个slave。
5.quorum和majority
每次一个哨兵做主备切换，首先需要quorum数量的哨兵认为odown，然后选举出一个哨兵来做主备切换，这个哨兵还要得到majority数量哨兵的授权，才能正式执行切换。
如果quorum < majority ,比如5个哨兵，majority就是3(超过半数)，quorum设置为2，那么就需要3个哨兵授权就可以执行切换。
如果 quorum >= majority，那么必须quorum数量的哨兵都授权才可以进行切换，比如5个哨兵，quorum是5，那么必须5个哨兵都同意授权，才可以进行切换。
6.configuration epoch
哨兵会对一套redis master+slave进行监控，有相应的监控的配置。
执行切换的那个哨兵，会从要切换到的新master（salve->master）那里得到一个configuration epoch，这就是一个version号，每次切换的version号都必须是唯一的。
如果第一个选举出的哨兵切换失败了，那么其他哨兵，会等待failover-timeout时间，然后接替继续执行切换，此时会重新获取一个新的configuration epoch，作为新的version号。
7、configuraiton传播
哨兵完成切换之后，会在自己本地更新生成最新的master配置，然后同步给其他的哨兵，就是通过之前说的pub/sub消息机制。
这里之前的version号就很重要了，因为各种消息都是通过一个channel去发布和监听的，所以一个哨兵完成一次新的切换之后，新的master配置是跟着新的version号的。
其他的哨兵都是根据版本号的大小来更新自己的master配置的。