深度長文整理-Redis進階

賜我白日夢發表於2020-09-19

一、基礎

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

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萬左右的連線。

參考(這個大佬講的超級好):https://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配置檔案可以看看這個博文:https://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出現集中式過期的情況

相關文章