一文讓你完全瞭解Redis(進階)，史上最全,不看後悔！！！【建議收藏】

1、Redis基礎

從新整理了一下，這篇筆記以前還有一篇基礎相關的筆記：
Redis基礎:http://www.javashuo.com/article/p-dfsikhqj-nx.html

2、爲何Redis是單線程的？

官方回答：Redis是基於內存操做，CPU不是Redis的性能瓶頸，Redis的性能瓶頸是機器的內存大小、以及網絡的帶寬，既然單線程容易實現，那就直接使用單線程來實現了

此外：使用單線程實現，那全部的命令就會排隊執行，不須要考慮各類同步問題和加鎖帶來的性能消耗問題。

既然CPU不是Redis的瓶頸，那麼若是不想讓服務器的其餘CPU閒置，能夠考慮起多個Redis進程，由於Redis不是關係型數據庫，數據之間也沒有約束。這樣還能搭建集羣，分壓分流。

3、爲何單線程這麼快？

1. Redis是一款內存數據庫，基於內存的讀寫速度原本就很快
2. 若是使用多線程的話會有線程上下文的切換。對於內存系統來講，單線程操做內存的效率纔是最高的。
3. Redis使用了epoll IO多路複用，能夠實現用一條線程處理併發的網絡請求

4、select、poll、epoll

select、poll、eopll是操做系統處理網絡上傳輸過來的數據的不一樣實現，數據從通過網線流入網卡，網卡中的驅動程序會向CPU發出中斷信號，在交互系統中，中斷信號的優先級是很高的，CPU馬上去處理這個中斷信息，CPU經過終端表找到相應的處理函數：
一、禁用網卡的中斷信號，告訴網卡下次有數據過來直接寫內存就ok
二、經過驅動程序申請、初始化一塊內存，將網卡中的數據寫進內存中
三、而後解析處理數據：操做系統先校驗數據是否符合os structure、數據往上層傳遞，Ehthernet校驗數據是否符合預期的格式，繼續向上層傳遞到ip層，再往上到tcp/udp層並按照指定的協議去解析
四、應用層想使用這部分數據就有一個拆包+格式校驗的過程

內存指的socket文件的接受緩衝區

做爲一個網絡服務器同一時刻可能有多個socket和他創建鏈接與他進行數據的交互，這裏的select、poll、epoll說的其實就是在衆多的socket中如何快速高效的找到接受緩衝區存在數據的socket文件，而後交給應用層的代碼去處理它

Select模型

做系統爲每個Tcp鏈接都會相應的建立sock文件，這些sock文件隸屬於操做系統的文件列表。

當sock收到了數據，會調用中斷程序喚醒進程A，將進程A從全部的Sock的等來隊列中移除，加入到內核空間的工做隊列中進程A只知道至少有一個sock的接受緩衝區已經由數據了，可是它不知道究竟是哪一個sock，因此它得經過遍歷sock列表的方式找到這個sock。

select的缺點和不足：

1. 進程A須要添加進全部的sock的等待隊列中，這會進行一次遍歷。
2. 當有sock就收到數據時，又得將進程A從全部的sock等待隊列中移除，這又是一次遍歷。 進程A尋找有數據的sock時，還會發生一次遍歷。
3. 爲了放置單個進程將系統的全部資源都耗幹，linux會限制單個進程能打開的fd文件句柄數，即便你能夠修改配置，突破這會個限制

下圖截自《UNIX環境高級編程》第二版

上圖能夠看到，使用select系統調用上有三個核心參數：分別是 readfds、writefds、exceptfds指向文件描述符號指針，每一個描述符都被放在fd_set中， 也就是說針對read、write、和except分別對應着一個獨立的fd_set , (並無網上流傳的數組哦，至少《UNIX環境高級編程》是這樣講的)

下圖是截取自《UNIX環境高級編程》的關於fd_set的相關信息，fd_set 是一個bit mask，不是數組。

Poll模型

網上一直流傳着這樣一句話：poll本質上和select沒有區別，都會進行好幾回無謂的遍歷才能找到究竟是那個sock文件的接受緩衝區中接受到了數據。

下圖是我截自《UNIX環境高級編程》關於poll部分的內容

書中關於poll的描述，poll模型中定義了一個pollfd，對fd進行了封裝，也就是說，poll是使用數組來保存fd的，就是上圖中的pollfd數組

網上流傳的另外一個版本就是說：poll使用鏈表維護着fd，因此poll沒有最大鏈接數的限制，這一點有待證明，至少《UNIX環境高級編程》中對鏈表的事隻字未提

從書中的描述看，poll確實是用數組來維護fd的，而且還本身封裝了個pollfd，維護的是pollfd數組，那爲何poll沒有鏈接數的限制呢？

我是這樣理解的：select之因此受到能僅僅能打開1024的限制，是由於操做系統層面上默認就有對單個進程能打開fd的做出的限制，好比32位的OS默認就是1024。那我用poll同也會受到這個1024的限制，可是我能修改這個限制，讓他變得比1024大。好比改爲10萬（只要你的服務器性可以好就行，數組中就能存更多的fd，遍歷處理起來就更快）。因此這纔會說，poll理論上能夠沒有限制。

固然我上面說的不必定就對，若是你有更好的解析，歡迎留言。

Epoll模型

Epoll的設計目標就是優化掉Select 和 Poll模型中查找接收到數據的sock文件時進行的無謂的遍歷操做。

看上圖：在select模型中，須要將進程添加進每個sock的等待隊列，而後阻塞，假如10萬TCP鏈接對應着10萬個sock文件，那這個添加+阻塞的操做就得重複10萬次

對於epoll來講能夠看到，這個添加的過程只進行了一次…見下圖

int s = socket(AF_INET, SOCK_STREAM, 0);   
bind(s, ...)
listen(s, ...)
 
int epfd = epoll_create(...);
epoll_ctl(epfd, ...); //將全部須要監聽的socket添加到epfd中
 
while(1){ 
    int n = epoll_wait(...)
    for(接收到數據的socket){ 
        //處理
    }

當執行系統調用 epoll_create(…) 內核會建立上圖中的eventpoll對象，eventpoll對象也隸屬於操做系統的文件系統，此外全部的sock都註冊在eventpoll中。

進程再也不註冊在每個sock的等待隊列中，而是註冊在eventpoll的等待隊列中，此外，接受緩衝區存在數據的sock會被註冊進eventpoll的rdlist中。這樣當進程再次被喚醒添加到操做系統的工做隊列中時，從eventpoll的rdlist中就能確切的獲取到哪些sock是須要處理的sock，免去了遍歷之苦。

eventpoll中的數據結構

rdlist: 裏面存放就緒列的socket，爲了知足快速方便刪除、添加。它被設計成了雙向鏈表

epoll中也是須要保存受監視的sock，爲了方便添加、搜索、檢索。被設計成紅黑樹。由於它的搜索、插入、刪除的時間複雜度都是O(logN)

Epoll的鏈接數有上限，可是很大，1G內存的機器上能夠打開10萬左右的鏈接，2G內存的機器能夠打開20萬左右的鏈接。

5、Redis的事務

原子性：一組命令要麼同時成功，要麼同時失敗

可是redis中的每一條單獨的命令是有原子性的，可是Redis中的事務不能保證原子性

redis中的事務沒有隔離級別的概念，不可能出現髒讀、幻讀、不可重複讀

在redis中，事務的本質是一組命令的集合，一個事務中的全部命令都會有被序列化，在事務執行的過程當中：順序、排他、一次性執行。

Redis事務的過程：

• 開啓事務
• 一連串普通命令
• 執行事務

# 開啓事務
127.0.0.1:16379> MULTI
OK

# 添加命令
127.0.0.1:16379> SET k1 v1
QUEUED
127.0.0.1:16379> SET k2 v2
QUEUED

# 執行事務
127.0.0.1:16379> EXEC
1) OK
2) OK
127.0.0.1:16379>

# 開啓事務
127.0.0.1:16379> MULTI
OK
# 添加命令
127.0.0.1:16379> set k3 v3
QUEUED
127.0.0.1:16379> SET k4 v4
QUEUED
# 取消事務
127.0.0.1:16379> DISCARD
OK
# 檢查結果，確實沒有執行剛剛添加的命令
127.0.0.1:16379> keys *
1) "k1"
2) "k2"
127.0.0.1:16379>

假設開啓時候後，多條命令中有一個命令出現運行時異常有什麼影響？

出現異常的命令不會被執行，可是這個異常的命令不會影響它後面的命令執行，由於這個緣由咱們說redis的事務不支持原子性

# k1的值爲字符串
127.0.0.1:16379> set k1 "v1"
OK
# 開啓事務
127.0.0.1:16379> MULTI
OK
# 設置事務的值
127.0.0.1:16379> set k2 v2
QUEUED
# 對字符串類型的值+1，會拋出運行時異常
127.0.0.1:16379> INCR k1
QUEUED
# 繼續添加兩個值
127.0.0.1:16379> set k3 v3
QUEUED
127.0.0.1:16379> set k4 v4
QUEUED
# 執行事務，看到，運行時異常的命令不會影響後續的命令執行
127.0.0.1:16379> exec
1) OK
2) (error) ERR value is not an integer or out of range
3) OK
4) OK
127.0.0.1:16379>

假設開啓時候後，多條命令中有一個命令出現編譯異常有什麼影響？

出現編譯型異常，全部的命令都不會被執行

# 開啓事務
127.0.0.1:16379> MULTI
OK
# 往命令隊列中添加命令
127.0.0.1:16379> set k1 v1
QUEUED
127.0.0.1:16379> set k2 v2
QUEUED
# 故意添加一個語法錯誤的命令，致使編譯異常
127.0.0.1:16379> GETSET k3
(error) ERR wrong number of arguments for 'getset' command
127.0.0.1:16379> set k4 v4
QUEUED
# 執行事務
127.0.0.1:16379> exec
(error) EXECABORT Transaction discarded because of previous errors.
# 檢查結果，發現全部的命令都沒有被執行
127.0.0.1:16379> keys *
(empty list or set)
127.0.0.1:16379>

CAP理論

nosql一樣也有一套屬於本身的CAP

• C(Consistency 強一致性)
• A(Availability可用性)
• P(Partition tolerance分區容錯性)

CAP 的理論核心是: 一個分佈式的系統,不可能很好的知足一致性,可用性,分區容錯性這三個需求,最多同時只能知足兩個.所以CAP原理將nosql分紅了三大原則:

• CA- 單點集羣,知足強一致性和可用性,好比說oracle,擴展性收到了限制
• CP- 知足一致性,和分區容錯性Redis和MongoDB都屬於這種類型
• AP- 選擇了可用性和分區容錯性,他也是大多數網站的選擇,容忍數據能夠暫時不一致,可是不容忍系統掛掉

6、Redis的監控

redis可以使用watch監視某一個key，而後開啓事務操做某一個key，當key沒有發生異常變更時，事務正常結束

一旦事務成功執行後，watch就會自動取消掉

127.0.0.1:16379> set money 100
OK
127.0.0.1:16379> set out 0
OK
# 監視key
127.0.0.1:16379> WATCH money
OK
127.0.0.1:16379> MULTI
OK
127.0.0.1:16379> DECRBY money 20
QUEUED
127.0.0.1:16379> INCRBY out 20
QUEUED
127.0.0.1:16379> exec
1) (integer) 80
2) (integer) 20

下面演示一個出現異常的例子：

事務中，添加watch的key被修改後，執行事務返回nil，表示失敗

驗證了watch機制使用的是樂觀鎖機制

當遇到上面這種返回nil的狀況下，能夠像下面這樣處理

# 取消監視（解鎖）
127.0.0.1:16379> UNWATCH
OK
# 從新監視
127.0.0.1:16379> watch money
OK
# 從新開啓事務
127.0.0.1:16379> MULTI
OK
127.0.0.1:16379>

7、Redis的配置文件

## 啓動redis的方式
./redis-server /path/to/redis.conf

# 能夠像下面這樣讓在當前配置文件包含引用其餘配置文件
include /path/to/local.conf
include /path/to/other.conf

# 指定哪些客戶端能夠鏈接使用redis
Examples:
bind 192.168.1.100 10.0.0.1  # 指定ip
bind 127.0.0.1 ::1 # 僅限於本機可訪問

# 是否處於受保護的模式，默認開啓
protected-mode yes

# 對外暴露的端口
port 16379

# TCP的通用配置
tcp-backlog 511
timeout 0
tcp-keepalive 300

# 是否以守護進程的方式運行，默認爲no
daemonize yes

# 若是進程在後臺運行，須要指定這個pid文件
pidfile /var/run/redis_6379.pid

# 日誌級別
# debug 測試開發節點
# verbose (和dubug很像，會產生大量日誌)
# notice (生產環境使用)
# warning (only very important / critical messages are logged)
loglevel notice

# 日誌文件名
logfile ""

# 數據庫的數量，默認16個
databases 16

# 是否老是顯示logo
always-show-logo yes


# 設置redis的登錄密碼（默認沒有密碼）
# 設置完密碼後，使用redis-cli登錄時，使用auth password 認證登錄
requirepass foobared

# 設置能鏈接上redis的客戶端的最大數量
maxclients 10000

# 給redis設置最大的內存容量
maxmemory <bytes>

# 內存達到上限後的處理策略
# volatile-lru -> 只針對設置了過時時間的key進行LRU移除
# allkeys-lru -> 刪除LRU算法的Key
# volatile-lfu -> 使用具備過時集的密鑰在近似的LFU中進行驅逐。
# allkeys-lfu -> 使用近似的LFU退出任何密鑰。
# volatile-random -> 隨機刪除即將過時的key
# allkeys-random -> 隨機刪除
# volatile-ttl -> 刪除即將過時的
# noeviction -> 永不過時，返回錯誤
maxmemory-policy noeviction

8、Redis的持久化

8.一、fork()系統調用
這裏很突兀的來個fork()系統調用緣由是應爲：Redis的單線程的，那若是主線程去作這種耗時的IO同步操做時，Redis總體的性能會被拖垮的。

fork()它是一個系統調用，通常用它來建立一個和當前進程如出一轍的子進程。當在程序中調用它時，系統爲新的進程分配存儲、資源，將原程序中的值也複製給他。

fork()函數調用一次會返回兩次，在父進程獲得的返回值是子進程的pid，在子進程中獲得的是0，出錯則返回負數。

Redis的實現是經過fork()系統調用建立一個子進程。 由這個子進程去負責執行這些耗時的IO操做，父子進程會共享內存，而後被共享的這塊內存不可寫，新的數據寫入到新的內存文件中

8.二、RDB

寫RDB文件是Redis的一種持久化方式。在指定的時間間隔內將內存中的數據寫入到磁盤，RDB文件是一個緊湊的二進制文件，每個文件都表明了某一個時刻（執行fork的時刻）Redis完整的數據快照，恢復數據時，將快照文件讀入內存便可。

RDB持久化的詳細過程:

Redis會經過系統調用fork()出一個子進程，父子進程是會共享內存的，父進程和子進程共享的這塊內存就是在執行fork操做那個時刻的內存快照。由linux的copy on write機制將父子進程共享的這塊內存標記爲只讀狀態。

此時對子進程來講，它的任務就是將這塊只讀內存中的數據保存成RDB文件。

對父進程來講它是有可能收到寫命令的，當父進程嘗試往這個加了只讀狀態的內存地址寫入數據時，就會觸發保護異常，執行linux的 copy on write，也就是將原來內存對應的數據頁複製出來一份後，而後對這個副本進行修改。

**這裏就會出現一個丟數據的概念：**你想，fork出來的子進程將要保存的數據是執行fork系統調用那個時刻的內存中的數據，很快這個內存就被標記爲只讀了，後續的增量數據沒有寫入到這個只讀內存中，那就算是RDB成功生成了，而後好巧，Redis掛了，這些增量的數據就會丟（因此得使用AOF輔助）
第二種RDB出現數據的丟失的狀況是：RDB過程當中，直接失敗了，文件都沒生成，不光是增量數據，原來的數據都丟了。

RDB相關配置以下:

# 把下面的註釋打開就會禁用掉RDB的持久化策略
# save ""

# 快照相關，指的是在規定的時間內執行了多少次操做纔會持久化到文件
save 900 1 # 900秒內1次
save 300 10 # 300秒內10次
save 60 10000 # 60秒內1萬次

# 持久化出錯了，是否讓redis繼續工做
stop-writes-on-bgsave-error yes

# 是否壓縮RBD文件（redis會採用LZF壓縮算法進行壓縮）須要消耗CPU資源
rdbcompression yes

# 保存rbc文件時是否檢驗rbd文件格式
# 使用CRC64算法進行數據校驗,可是這樣會增長大約 10%的性能消耗
rdbchecksum yes

# dump DB的文件名
dbfilename dump.rdb

# rdb文件的持久化目錄（當前目錄）
dir ./

觸發保存RDB文件4種狀況:

1. 手動執行save命令、bgsave
2. 知足配置文件中配置的save相關配置項時，自動觸發
3. 手動執行flushall
4. 關閉redisshutdown

如何讓redis加載rdb文件？

只須要將rdb文件放在redis的啓動目錄下，redis其中時會自動加載它

RDB模式的優缺點：

優勢：RDB過程當中，由子進程代替主進程進行備份的IO操做。保證了主進程仍然提供高性能的服務。適合大規模的數據備份恢復過程。

缺點：

1. 默認狀況下，它是每隔一段時間進行一次數據備份，因此一旦出現最後一次持久化的數據丟失，將丟失大規模的數據。
2. fork()子進程時會佔用必定的內存空間，若是在fork()子進程的過程當中，父進程夯住了，那也就是redis卡住了，不能對外提供服務。因此不要讓生成RDB文件的時間間隔太長，否則每次生成的RDB文件過大對Redis自己也是有影響的。

8.三、AOF
AOF是什麼？

Append Only File，他也是Redis的持久化策略。即將全部的寫命令都以日誌的方式追加記錄下來（只追加，不修改），恢復的時候將這個文件中的命令讀出來回放。

當咱們執行 flushall 命令,清空了redis在內存中的數據，appendonly.aof 一樣會記錄下這條命令,因此,咱們想恢復數據的話,須要去除 appendonly.aof 裏面的 flushall 命令

AOF相關的配置

# 默認不開啓aof
appendonly no

# aof文件名
appendfilename "appendonly.aof"

# redis經過fsync()調用告訴操做系統實際在磁盤上寫入數據
# aof文件落盤的策略
# appendfsync always 每次發生數據變動,馬上記錄到磁盤，可是致使redis吞吐量下降
# appendfsync everysec 可能會丟失1秒的數據
# appendfsync no
appendfsync everysec

# 當時用bfwriteaof時，fork一個子進程寫aof文件，就算aof文件很大，也不會阻塞主進程
# 意外狀況：可是當主進程、子進程同時寫aof文件時，可能會出現因爲子進程大量的IO操做阻塞主進程
# 當出現這種意外狀況時：設置這個參數爲no，能夠保證數據不會丟失，可是得容忍主進程被阻塞
# 當出現這種意外狀況時：設置這個參數爲yes,主進程不會被阻塞主，可是不保證數據安全性
# 綜上：若是應用沒法忍受延遲：設置爲yes。沒法忍受數據丟失：設置爲no
no-appendfsync-on-rewrite no

# 在當前aof文件的體積超過上次aof文件的體積的100%時，寫新文件
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb # 最開始的aof文件體積至少達到60M時才重寫

# 回放aof文件時，若是最後一條命令存在問題，是否容許忽略
aof-load-truncated yes

# 是否容許AOF和RDB這兩種持久化方式並存
aof-use-rdb-preamble yes

當aof文件出錯怎麼辦？

redis爲咱們提供了修復aof文件的工具

[root@instance-lynj0v9k-19 bin]# redis-check-aof  --fix appendonly.aof

aof模式的優缺點優勢：

1. aof是用追加的形式寫，沒有隨機磁盤IO那樣的尋址開銷，性能仍是比較高的。
2. aof能夠更好的保護數據不丟失或者儘量的少丟失：設置讓redis每秒同步一次數據，即便redis宕機了，最多也就丟失1秒的數據。
3. 即便aof真的體積很大，也能夠設置後臺重寫，不影響客戶端的重寫。
4. aof適合作災難性的誤刪除緊急恢復：好比不當心執行了flushall，而後能夠在發生rewrite以前 快速備份下aof文件，去掉末尾的flushall，經過恢復機制恢復數據

缺點：使用aof一直追加寫，致使aof的體積遠大於RDB文件的體積，恢復數據、修復的速度要比rdb慢不少。

aof的重寫

AOF採起的是文件追加的方式,文件的體積愈來愈大,爲了優化這種現象,增長了重寫機制,當aof文件的體積到達咱們在上面的配置文件上的闋值時,就會觸發重寫策略,只保留和數據恢復相關的命令

手動觸發重寫

# redis會fork出一條新的進程
# 一樣是先複製到一份新的臨時文件,最後再rename,遍歷每一條語句,記錄下有set的語句
bgrewriteaof

8.四、RDB和AOF的選擇

若是咱們的redis只是簡單的做爲緩存，那二者都不要也沒事
若是數據須要持久化，那不要僅僅使用RDB，由於一旦發生故障，你會丟失不少數據
同時開啓二者: 在這種狀況下,redis優先加載的是aof,由於它的數據極可能比rdb更全,可是並不建議只是用aof,由於aof不是那麼的安全,極可能存在潛在的bug

推薦：

建議在從機slave上只備份rdb文件，並且只要15分鐘備份一次就夠了。
若是啓動了aof,咱們儘可能減小rewrite的頻率,基礎大小設置爲5G徹底能夠,起步也要3G。
若是咱們不選擇aof, 而是選擇了主從複製的架構實現高可用一樣能夠,能省掉一大筆IO操做,可是意外發生的話,會丟失十幾分鐘的數據。

9、發佈訂閱

Redis的發佈訂閱模型是一種：消息通訊方式，發佈者發送到redis到隊列中，消息的訂閱者能夠接收到消息，Redis的客戶端能夠訂閱任意數量的消息

應用場景：關注訂閱、消息推送、實時廣播、網絡聊天室

有新消息經過 PUBLISH 命令發送給頻道 channel1 時， 這個消息就會被髮送給訂閱它的三個客戶端

測試發佈、訂閱

10、主從複製

概念：和MySQL的主從複製的概念大同小異，分紅leader節點和follower節點，主節點承接線上的寫流量，從節點承接線上的讀流量爲主庫分流減壓，從庫的數據從主庫中同步過來

主從複製的做用：

1. 理論上主庫從庫的數據是須要保持的，這也是一種數據冗餘熱備份的機制
2. 故障恢復：當leader節點出現故障時，能夠由從節點提供服務，保證應用的可用性
3. 負載均衡：在主從複製的接觸上，能夠將客戶端的讀寫不一樣類型的流量分攤到不一樣的機器上，分流減壓
   主從複製+哨兵，構建高可用的redis集羣，解決了單點故障問題
   

11、集羣搭建及小實驗

redis默認本身就是一個主庫，因此咱們搭建主從架構的redis，只須要配置Redis從庫。

11.一、架構一：一主兩從
下面搭建這樣的一主兩從的redis集羣

若是是在一臺服務器上啓動多臺Redis，須要修改一下配置文件中的端口、pid文件名、日誌名、dump.db名

啓動三臺redis

讓1637八、16377認16379爲leader，執行以下命令：

搭建完主從環境以後，查看是否能夠從slave中寫入數據：

# 結果很明顯，不能寫入
127.0.0.1:16378> set k1 v0
(error) READONLY You can't write against a read only replica.

MySQL中只要你不設置從庫read only，從庫也是能夠寫入的併產生本身的binlog的

測試：從master寫入，從slave讀出

測試：主機宕機，slave有什麼表現

主機宕機後，從庫的role依然是slave，而且顯示master的狀態爲down

測試：主機宕機後又重啓了，slave有什麼表現

主機重啓後，slave會重連主機，主機的狀態爲up，salve能夠正常在主庫上同步數據

測試：從機宕機，而後有新數據寫到了主庫，從機再重啓問：重啓後的從機能不能獲取到她宕機期間主庫的增量數據？

答案是：獲取不到了，由於若是是經過命令行搭建的主從，從庫一旦重啓，角色會變回master

若是這時再把16378變成16379的從庫，問能不能獲取到增量數據呢？

全量複製和增量複製

從庫第一次鏈接到主庫上確定會進行一次全量複製，即：master會啓動後臺的存盤進程，同時收集全部用於修改數據集的命令，在後臺完成同步，而後將整個數據文件發送給slave，讓slave完成一次數據的全量複製

除第一次複製數據以外的主從複製都是增量複製，即master僅僅會將收到的增量寫命令發送給slave。

11.二、架構二

其中的17378既是Master又是Slave

對於16377來講，它確實認了16378爲主，可是16378自己又是16379的slave，因此他們之間數據同步的走向是 ： 16379 --> 16378 --> 16377 ，對於16378來講，即便有實例認它當master，它依然是不能寫

若是主庫16379宕機了，16378的狀態依然是slave，而且它能察覺master已經掛了，執行 slave no one, 能夠將本身提高爲master。 在整個過程當中，16377不受影響

即便舊master開機重啓了，舊的master依然是master，也不能自動的加入到 16377 16378集羣中

11.三、架構三：Sentinel
上面的兩種架構模式中，主庫掛了以後都須要人爲的去選舉一個的新的master來承接讀流量

redis2.8之以後，提供了哨兵模式：哨兵監控到當主服務器掛了，發起投票選新主庫，實現自動的完成選主，承接線上寫流量，完成止損

哨兵做爲一個獨立的進程存在，原理是：哨兵經過發送命令和redis服務器交互，從而監控運行整個集羣中的多個Redis實例

Redis的哨兵在Redis 的安裝目錄下能夠找到

爲了防禦哨兵出現單點故障，因此一般使用多個哨兵對集羣進行監控

集羣中的每一個哨兵彼此相互監控，每一個哨兵也都監控着集羣中的全部Redis實例

主觀下線和客觀下線

當一個哨兵發現master不可用時，系統不會立刻進行failover，僅僅是這一個哨兵主觀意義上認爲這個master不可用，這時若是其餘的哨兵也來探測master，而且大部分的哨兵都主觀認爲master確實不可用了，哨兵們就會投票在slave中選出一個當得票最多的slave做爲新的master。進行failover操做。

經過發佈訂閱的模式，哨兵告訴本身監控的那些服務器將master切換爲剛剛的票最多的那個實例，這個過程就叫作客觀下線。

集羣搭建

首先是建立一主二從的redis集羣, 此處省略，參照上面架構1部分便可

編寫sentinel的配置文件，配置文件的名稱、配置項不能寫錯～

# myredis1 監控的這個redis實例啥
# 127.0.0.1 監控的這個redis實例的ip
# 16379 監控的這個redis實例的端口
# 1 監控的這個redis實例的掛了後，自動投票選主
sentinel monitor myredis1 127.0.0.1 16379 1

啓動sentinel

這樣，當master宕機後，哨兵會自動選擇一個新的slave做爲新主，主庫重啓後，sentinel會將其做爲slave自動加入到現有的redis集羣中。

12、緩存穿透、緩存擊穿、雪崩

緩存穿透

好比這種應用場景：使用redis緩存用戶信息，當有新用戶註冊時先將用戶的信息寫入Mysql，而後寫入Redis。有修改操做時，修改完MySQl中的數據後，同步的也會修改Redis中的數據，並且咱們也沒有給Redis中的key設置過時時間。（這就意味着：數據庫中有指定的KV的信息的話，緩存中也會有。那當用戶查詢時緩存中沒有的話，說明數據庫中99.999%也不會有）

這時候有大量的請求去訪問MySQL中都沒有都數據時，請求先打向了Redis，Redis中確定也沒有存儲用戶查詢的數據，因此大量的請求一會兒打到了數據庫上，瞬間擊垮數據庫，這種現象稱爲緩存穿透。

解決方案：

布隆過濾器：

布隆過濾器能夠理解成一個bit數組，數組中每個非0即1

客戶端的請求統一先打向布隆過濾器，布隆過濾器放在應用的控制層，布隆過濾器中存在多個hash函數，分別對這個key進行hash獲得hashcode，而後將hashcode%數組長度，將算出來的下標標記爲1。

key以此通過全部hash，再%size算出的下標對應的值，只要存在一個不爲1的數，咱們就認爲key沒在緩存中，直接丟棄用戶的此次請求，符合要求把請求打向Redis。從而避免這個請求對底層存儲的查詢壓力。

緩存空對象：

當用戶查詢的時候，若是發現緩存中沒有，就往緩存中放置一個空的對象，而後返回給用戶這個控對象，也能避免用戶的請求直接打向數據庫。

緩存擊穿：

緩存擊穿指的是Redis中確確實實存在用戶查詢的key，可是呢用戶的訪問頻率太猛烈了，致使Redis扛不住掛了，致使大量的請求直接打向數據庫，或者當某一個key的過時時間到了的瞬間，大量的請求打向數據庫致使數據庫直接掛了

解決方案：

設置key永不過時

加互斥鎖：對這個查詢操做添加分佈式鎖，將原來的大併發直接訪問緩存轉換成了併發獲取分佈式鎖，只有獲取到分佈式鎖後才能去查詢緩存。

雪崩：

比咱們啓動redis進行一些數據預熱，就是將一些數據庫中的數據提早導入到redis中，而後給這些數據設置了過時時間。

搶購時間一到系統迎來了一大批併發，可是因爲緩存中的數據充足，因此能扛住這波併發。一段時間後，redis中的key集中式的過時了，這時再來一大批併發請求可能就直接將redis打垮。redis掛了後，大量的請求直接打向MySQL，致使MySQL跟着雪崩式的垮掉

解決方法：異地多活，添加redis的實例的數量

加分佈式鎖

在應用和緩存之間添加消息中間件作緩衝

合理爲不一樣的key設置不一樣的過時時間，放置緩存中的key出現集中式過時的狀況.