深度長文整理-Redis進階

目錄

一、基礎

重新整理了一下，這篇筆記之前還有一篇基礎相關的筆記，點擊進入

image-20200919193313950

二、為什麼Redis是單執行緒的？

官方回答：

Redis是基於記憶體操作，CPU不是Redis的性能瓶頸，Redis的性能瓶頸是機器的記憶體大小、以及網路的頻寬，既然單執行緒容易實現，那就直接使用單執行緒來實現了

此外：

使用單執行緒實現，那所有的命令就會排隊執行，不需要考慮各種同步問題和加鎖帶來的性能消耗問題。

既然CPU不是Redis的瓶頸，那麼如果不想讓伺服器的其他CPU閑置，可以考慮起多個Redis進程，因為Redis不是關係型資料庫，數據之間也沒有約束。這樣還能搭建集群，分壓分流。

三、為什麼單執行緒這麼快？

  1. Redis是一款記憶體資料庫，基於記憶體的讀寫速度本來就很快
  2. 如果使用多執行緒的話會有執行緒上下文的切換。對於記憶體系統來說，單執行緒操作記憶體的效率才是最高的。
  3. Redis使用了epoll IO多路復用，可以實現用一條執行緒處理並發的網路請求

四、select、poll、epoll

select、poll、eopll是作業系統處理網路上傳輸過來的數據的不同實現，數據從經過網線流入網卡，網卡中的驅動程式會向CPU發出中斷訊號，在交互系統中，中斷訊號的優先順序是很高的，CPU立刻去處理這個中斷資訊，CPU通過終端表找到相應的處理函數：

1、禁用網卡的中斷訊號，告訴網卡下次有數據過來直接寫記憶體就ok

2、通過驅動程式申請、初始化一塊記憶體，將網卡中的數據寫進記憶體中

3、然後解析處理數據：作業系統先校驗數據是否符合os structure、數據往上層傳遞，Ehthernet校驗數據是否符合預期的格式，繼續向上層傳遞到ip層，再往上到tcp/udp層並按照指定的協議去解析

4、應用層想使用這部分數據就有一個拆包+格式校驗的過程

記憶體指的的socket文件的接受緩衝區。

作為一個網路伺服器同一時刻可能有多個socket和他建立連接與他進行數據的交互，這裡的select、poll、epoll說的其實就是在眾多的socket中如何快速高效的找到接受緩衝區存在數據的socket文件，然後交給應用層的程式碼去處理它

Select模型

作業系統為每一個Tcp連接都會相應的創建sock文件，這些sock文件隸屬於作業系統的文件列表。

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

select的缺點和不足：

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

Poll模型

poll本質上和select沒有區別，都會進行好幾次無謂的遍歷才能找到到底是那個sock文件的接受緩衝區中接受到了數據。

優點：它沒有最大連接數的限制，原因是它是基於鏈表來存儲的文件句柄的

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，免去了遍歷之苦

Epoll的連接數有上限，但是很大，1G記憶體的機器上可以打開10萬左右的連接，2G記憶體的機器可以打開20萬左右的連接。

參考(這個大佬講的超級好)：//zhuanlan.zhihu.com/p/63179839

五、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- 選擇了可用性和分區容錯性,他也是大多數網站的選擇,容忍數據可以暫時不一致,但是不容忍系統掛掉

六、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機制使用的是樂觀鎖機制

image-20200919095619327

當遇到上面這種返回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>

七、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

八、Redis的持久化

8.1、fork()系統調用

這裡很突兀的來個fork()系統調用原因是應為：Redis的單執行緒的，那如果主執行緒去做這種耗時的IO同步操作時，Redis整體的性能會被拖垮的。

fork()它是一個系統調用，一般用它來創建一個和當前進程一模一樣的子進程。當在程式中調用它時，系統為新的進程分配存儲、資源，將原程式中的值也複製給他。

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

Redis的實現是通過fork()系統調用創建一個子進程。 由這個子進程去負責執行這些耗時的IO操作，父子進程會共享記憶體，然後被共享的這塊記憶體不可寫，新的數據寫入到新的記憶體文件中

8.2、RDB

寫RDB文件是Redis的一種持久化方式。在指定的時間間隔內將記憶體中的數據寫入到磁碟，RDB文件是一個緊湊的二進位文件，每一個文件都代表了某一個時刻（執行fork的時刻）Redis完整的數據快照，恢複數據時，將快照文件讀入記憶體即可。

RDB持久化的詳細過程:

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

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

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

這裡就會出現一個丟數據的概念：你想，fork出來的子進程將要保存的數據是執行fork系統調用那個時刻的記憶體中的數據，很快這個記憶體就被標記為只讀了，後續的增量數據沒有寫入到這個只讀記憶體中，那就算是RDB成功生成了，這些增量的數據依然會丟（所以得使用AOF輔助）

第二種RDB出現數據的丟失的情況是：RDB過程中，直接失敗了，文件都沒生成，不光是增量數據，原來的數據都丟了。

參考：linux的copy on write

歡迎關注大佬：三國夢回

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.3、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文件的工具

image-20200919120015772

[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.4、RDB和AOF的選擇

  • 如果我們的redis只是簡單的作為快取，那兩者都不要也沒事
  • 如果數據需要持久化，那不要僅僅使用RDB，因為一旦發生故障，你會丟失很多數據
  • 同時開啟兩者: 在這種情況下,redis優先載入的是aof,因為它的數據很可能比rdb更全,但是並不建議只是用aof,因為aof不是那麼的安全,很可能存在潛在的bug

推薦：

  • 建議在從機slave上只備份rdb文件，而且只要15分鐘備份一次就夠了。
  • 如果啟動了aof,我們盡量減少rewrite的頻率,基礎大小設置為5G完全可以,起步也要3G。
  • 如果我們不選擇aof, 而是選擇了主從複製的架構實現高可用同樣可以,能省掉一大筆IO操作,但是意外發生的話,會丟失十幾分鐘的數據。

九、發布訂閱

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

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

chanel1頻道

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

訂閱發布

測試發布、訂閱

image-20200919141129930

十、主從複製

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

主從複製的作用：

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

十一、集群搭建及小實驗

redis默認自己就是一個主庫，所以我們搭建主從架構的redis，只需要配置Redis從庫。

image-20200919142947104

11.1、架構一：一主兩從

下面搭建這樣的一主兩從的redis集群

image-20200919152728847

role ip port
主庫 xxx 16379
從庫 xxx 16378
從庫 xxx 16377

如果是在一台伺服器上啟動多台Redis，需要修改一下配置文件中的埠、pid文件名、日誌名、dump.db名

啟動三台redis

image-20200919143804002

讓16378、16377認16379為leader，執行如下命令：

image-20200919145315854

搭建完主從環境之後，查看是否可以從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讀出

image-20200919145910731

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

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

image-20200919150316225

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

主機重啟後，slave會重連主機，主機的狀態為up，salve可以正常在主庫上同步數據

image-20200919150815126

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

答案是：獲取不到了，因為如果是通過命令行搭建的主從，從庫一旦重啟，角色會變回master

image-20200919151448322

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

image-20200919151904041

全量複製和增量複製

從庫第一次連接到主庫上肯定會進行一次全量複製，即：master會啟動後台的存檔進程，同時收集所有用於修改數據集的命令，在後台完成同步，然後將整個數據文件發送給slave，讓slave完成一次數據的全量複製

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

11.2、架構二

image-20200919154359193

其中的17378既是Master又是Slave

對於16377來說，它確實認了16378為主，但是16378本身又是16379的slave，所以他們之間數據同步的走向是 ： 16379 –> 16378 –> 16377 ，對於16378來說，即使有實例認它當master，它依然是不能寫

image-20200919154111295

如果主庫16379宕機了，16378的狀態依然是slave，並且它能察覺master已經掛了，執行 slave no one, 可以將自己提升為master。 在整個過程中，16377不受影響

即使舊master開機重啟了，舊的master依然是master，也不能自動的加入到 16377 16378集群中
image-20200919160136653

11.3、架構三：Sentinel

上面的兩種架構模式中，主庫掛了之後都需要人為的去選舉一個的新的master來承接讀流量

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

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

image-20200919161434493

Redis的哨兵在Redis 的安裝目錄下可以找到

image-20200919161605419

為了防護哨兵出現單點故障，所以通常使用多個哨兵對集群進行監控

集群中的每個哨兵彼此相互監控，每個哨兵也都監控著集群中的所有Redis實例

image-20200919162152949

主觀下線和客觀下線

當一個哨兵發現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

image-20200919164321594

這樣，當master宕機後，哨兵會自動選擇一個新的slave作為新主，主庫重啟後，sentinel會將其作為slave自動加入到現有的redis集群中

更多更詳細的sentinel配置文件可以看看這個博文：//www.cnblogs.com/heroinss/p/10340925.html

十二、快取穿透、快取擊穿、雪崩

快取穿透

比如這種應用場景：使用redis快取用戶資訊，當有新用戶註冊時先將用戶的資訊寫入Redis，然後寫入Mysql，有修改操作時，修改完MySQl中的數據後，同步的也會修改Redis中的數據，而且我們也沒有給Redis中的key設置過期時間。（這就意味著，資料庫中有指定的KV的資訊的話，快取中也會有。那當用戶查詢時快取中沒有的話，說明資料庫中99.999%也不會有）

這時候有大量的請求突然打向了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出現集中式過期的情況

Tags:

VirMach 便宜 VPS

QNews

QNews