就是如果你用redis快取技術的話，肯定要考慮如何用redis來加多臺機器，保證redis是高併發的，還有就是如何讓Redis保證自己不是掛掉以後就直接死掉了，redis高可用

我這裡會選用我之前講解過這一塊內容，redis高併發、高可用、快取一致性

redis高併發：主從架構，一主多從，一般來說，很多專案其實就足夠了，單主用來寫入資料，單機幾萬QPS，多從用來查詢資料，多個從例項可以提供每秒10萬的QPS。

redis高併發的同時，還需要容納大量的資料：一主多從，每個例項都容納了完整的資料，比如redis主就10G的記憶體量，其實你就最對只能容納10g的資料量。如果你的快取要容納的資料量很大，達到了幾十g，甚至幾百g，或者是幾t，那你就需要redis叢集，而且用redis叢集之後，可以提供可能每秒幾十萬的讀寫併發。

redis高可用：如果你做主從架構部署，其實就是加上哨兵就可以了，就可以實現，任何一個例項宕機，自動會進行主備切換。

redis如何通過讀寫分離來承載讀請求QPS超過10萬+

1、redis高併發跟整個系統的高併發之間的關係

redis，你要搞高併發的話，不可避免，要把底層的快取搞得很好

mysql，高併發，做到了，那麼也是通過一系列複雜的分庫分表，訂單系統，事務要求的，QPS到幾萬，比較高了

要做一些電商的商品詳情頁，真正的超高併發，QPS上十萬，甚至是百萬，一秒鐘百萬的請求量

光是redis是不夠的，但是redis是整個大型的快取架構中，支撐高併發的架構裡面，非常重要的一個環節

首先，你的底層的快取中介軟體，快取系統，必須能夠支撐的起我們說的那種高併發，其次，再經過良好的整體的快取架構的設計（多級快取架構、熱點快取），支撐真正的上十萬，甚至上百萬的高併發

2、redis不能支撐高併發的瓶頸在哪裡？

單機

3、如果redis要支撐超過10萬+的併發，那應該怎麼做？

單機的redis幾乎不太可能說QPS超過10萬+，除非一些特殊情況，比如你的機器效能特別好，配置特別高，物理機，維護做的特別好，而且你的整體的操作不是太複雜

單機在幾萬

讀寫分離，一般來說，對快取，一般都是用來支撐讀高併發的，寫的請求是比較少的，可能寫請求也就一秒鐘幾千，一兩千

大量的請求都是讀，一秒鐘二十萬次讀

讀寫分離

主從架構 -> 讀寫分離 -> 支撐10萬+讀QPS的架構

4、接下來要講解的一個topic

redis replication

redis主從架構 -> 讀寫分離架構 -> 可支援水平擴充套件的讀高併發架構
 

redis replication以及master持久化對主從架構的安全意義

課程大綱

1、圖解redis replication基本原理
2、redis replication的核心機制
3、master持久化對於主從架構的安全保障的意義

redis replication -> 主從架構 -> 讀寫分離 -> 水平擴容支撐讀高併發

redis replication的最最基本的原理，鋪墊

------------------------------------------------------------------------

1、圖解redis replication基本原理

------------------------------------------------------------------------

2、redis replication的核心機制

（1）redis採用非同步方式複製資料到slave節點，不過redis 2.8開始，slave node會週期性地確認自己每次複製的資料量
（2）一個master node是可以配置多個slave node的
（3）slave node也可以連線其他的slave node
（4）slave node做複製的時候，是不會block master node的正常工作的
（5）slave node在做複製的時候，也不會block對自己的查詢操作，它會用舊的資料集來提供服務; 但是複製完成的時候，需要刪除舊資料集，載入新資料集，這個時候就會暫停對外服務了
（6）slave node主要用來進行橫向擴容，做讀寫分離，擴容的slave node可以提高讀的吞吐量

slave，高可用性，有很大的關係

------------------------------------------------------------------------

3、master持久化對於主從架構的安全保障的意義

如果採用了主從架構，那麼建議必須開啟master node的持久化！
a
不建議用slave node作為master node的資料熱備，因為那樣的話，如果你關掉master的持久化，可能在master宕機重啟的時候資料是空的，然後可能一經過複製，salve node資料也丟了

master -> RDB和AOF都關閉了 -> 全部在記憶體中

master宕機，重啟，是沒有本地資料可以恢復的，然後就會直接認為自己IDE資料是空的

master就會將空的資料集同步到slave上去，所有slave的資料全部清空

100%的資料丟失

master節點，必須要使用持久化機制

第二個，master的各種備份方案，要不要做，萬一說本地的所有檔案丟失了; 從備份中挑選一份rdb去恢復master; 這樣才能確保master啟動的時候，是有資料的

即使採用了後續講解的高可用機制，slave node可以自動接管master node，但是也可能sentinal還沒有檢測到master failure，master node就自動重啟了，還是可能導致上面的所有slave node資料清空故障
 

 redis主從複製原理、斷點續傳、無磁碟化複製、過期key處理

1、主從架構的核心原理

當啟動一個slave node的時候，它會發送一個PSYNC命令給master node

如果這是slave node重新連線master node，那麼master node僅僅會複製給slave部分缺少的資料; 否則如果是slave node第一次連線master node，那麼會觸發一次full resynchronization

開始full resynchronization的時候，master會啟動一個後臺執行緒，開始生成一份RDB快照檔案，同時還會將從客戶端收到的所有寫命令快取在記憶體中。RDB檔案生成完畢之後，master會將這個RDB傳送給slave，slave會先寫入本地磁碟，然後再從本地磁碟載入到記憶體中。然後master會將記憶體中快取的寫命令傳送給slave，slave也會同步這些資料。

slave node如果跟master node有網路故障，斷開了連線，會自動重連。master如果發現有多個slave node都來重新連線，僅僅會啟動一個rdb save操作，用一份資料服務所有slave node。

2、主從複製的斷點續傳

從redis 2.8開始，就支援主從複製的斷點續傳，如果主從複製過程中，網路連線斷掉了，那麼可以接著上次複製的地方，繼續複製下去，而不是從頭開始複製一份

master node會在記憶體中常見一個backlog，master和slave都會儲存一個replica offset還有一個master id，offset就是儲存在backlog中的。如果master和slave網路連線斷掉了，slave會讓master從上次的replica offset開始繼續複製

但是如果沒有找到對應的offset，那麼就會執行一次resynchronization

3、無磁碟化複製

master在記憶體中直接建立rdb，然後傳送給slave，不會在自己本地落地磁碟了

repl-diskless-sync
repl-diskless-sync-delay，等待一定時長再開始複製，因為要等更多slave重新連線過來

4、過期key處理

slave不會過期key，只會等待master過期key。如果master過期了一個key，或者通過LRU淘汰了一個key，那麼會模擬一條del命令傳送給slave。
 

redis replication的完整流執行程和原理的再次深入剖析

1、複製的完整流程

（1）slave node啟動，僅僅儲存master node的資訊，包括master node的host和ip，但是複製流程沒開始

master host和ip是從哪兒來的，redis.conf裡面的slaveof配置的

（2）slave node內部有個定時任務，每秒檢查是否有新的master node要連線和複製，如果發現，就跟master node建立socket網路連線
（3）slave node傳送ping命令給master node
（4）口令認證，如果master設定了requirepass，那麼salve node必須傳送masterauth的口令過去進行認證
（5）master node第一次執行全量複製，將所有資料發給slave node
（6）master node後續持續將寫命令，非同步複製給slave node

2、資料同步相關的核心機制

指的就是第一次slave連線msater的時候，執行的全量複製，那個過程裡面你的一些細節的機制

（1）master和slave都會維護一個offset

master會在自身不斷累加offset，slave也會在自身不斷累加offset
slave每秒都會上報自己的offset給master，同時master也會儲存每個slave的offset

這個倒不是說特定就用在全量複製的，主要是master和slave都要知道各自的資料的offset，才能知道互相之間的資料不一致的情況

（2）backlog

master node有一個backlog，預設是1MB大小
master node給slave node複製資料時，也會將資料在backlog中同步寫一份
backlog主要是用來做全量複製中斷候的增量複製的

（3）master run id

info server，可以看到master run id
如果根據host+ip定位master node，是不靠譜的，如果master node重啟或者資料出現了變化，那麼slave node應該根據不同的run id區分，run id不同就做全量複製
如果需要不更改run id重啟redis，可以使用redis-cli debug reload命令

（4）psync

從節點使用psync從master node進行復制，psync runid offset
master node會根據自身的情況返回響應資訊，可能是FULLRESYNC runid offset觸發全量複製，可能是CONTINUE觸發增量複製

3、全量複製

（1）master執行bgsave，在本地生成一份rdb快照檔案
（2）master node將rdb快照檔案傳送給salve node，如果rdb複製時間超過60秒（repl-timeout），那麼slave node就會認為複製失敗，可以適當調節大這個引數
（3）對於千兆網絡卡的機器，一般每秒傳輸100MB，6G檔案，很可能超過60s
（4）master node在生成rdb時，會將所有新的寫命令快取在記憶體中，在salve node儲存了rdb之後，再將新的寫命令複製給salve node
（5）client-output-buffer-limit slave 256MB 64MB 60，如果在複製期間，記憶體緩衝區持續消耗超過64MB，或者一次性超過256MB，那麼停止複製，複製失敗
（6）slave node接收到rdb之後，清空自己的舊資料，然後重新載入rdb到自己的記憶體中，同時基於舊的資料版本對外提供服務
（7）如果slave node開啟了AOF，那麼會立即執行BGREWRITEAOF，重寫AOF

rdb生成、rdb通過網路拷貝、slave舊資料的清理、slave aof rewrite，很耗費時間

如果複製的資料量在4G~6G之間，那麼很可能全量複製時間消耗到1分半到2分鐘

4、增量複製

（1）如果全量複製過程中，master-slave網路連線斷掉，那麼salve重新連線master時，會觸發增量複製
（2）master直接從自己的backlog中獲取部分丟失的資料，傳送給slave node，預設backlog就是1MB
（3）msater就是根據slave傳送的psync中的offset來從backlog中獲取資料的

5、heartbeat

主從節點互相都會發送heartbeat資訊

master預設每隔10秒傳送一次heartbeat，salve node每隔1秒傳送一個heartbeat

6、非同步複製

master每次接收到寫命令之後，現在內部寫入資料，然後非同步傳送給slave node
 

 redis主從架構下如何才能做到99.99%的高可用性？

1、什麼是99.99%高可用？

架構上，高可用性，99.99%的高可用性

講的學術，99.99%，公式，系統可用的時間 / 系統故障的時間，365天，在365天 * 99.99%的時間內，你的系統都是可以嘩嘩對外提供服務的，那就是高可用性，99.99%

系統可用的時間 / 總的時間 = 高可用性，然後會對各種時間的概念，說一大堆解釋

2、redis不可用是什麼？單例項不可用？主從架構不可用？不可用的後果是什麼？

3、redis怎麼才能做到高可用？

高可用是什麼