深度長文整理-Redis進階

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

Redis

一、基礎

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

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

官方回答：

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

此外：

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

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

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

Redis是一款記憶體資料庫，基於記憶體的讀寫速度本來就很快
如果使用多執行緒的話會有執行緒上下文的切換。對於記憶體系統來說，單執行緒操作記憶體的效率才是最高的。
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的缺點和不足：

程式A需要新增進所有的sock的等待佇列中，這會進行一次遍歷。
當有sock就收到資料時，又得將程式A從所有的sock等待佇列中移除，這又是一次遍歷。
程式A尋找有資料的sock時，還會發生一次遍歷。
為了放置單個程式將系統的所有資源都耗幹，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機制使用的是樂觀鎖機制

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

手動執行save命令、bgsave
滿足配置檔案中配置的save相關配置項時，自動觸發
手動執行flushall
關閉redisshutdown

如何讓redis載入rdb檔案？

只需要將rdb檔案放在redis的啟動目錄下，redis其中時會自動載入它

RDB模式的優缺點：

優點：RDB過程中，由子程式代替主程式進行備份的IO操作。保證了主程式仍然提供高效能的服務。適合大規模的資料備份恢復過程。

缺點：

預設情況下，它是每隔一段時間進行一次資料備份，所以一旦出現最後一次持久化的資料丟失，將丟失大規模的資料。
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檔案的工具

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

aof模式的優缺點優點：

aof是用追加的形式寫，沒有隨機磁碟IO那樣的定址開銷，效能還是比較高的。
aof可以更好的保護資料不丟失或者儘可能的少丟失：設定讓redis每秒同步一次資料，即使redis當機了，最多也就丟失1秒的資料。
即使aof真的體積很大，也可以設定後臺重寫，不影響客戶端的重寫。
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

九、釋出訂閱

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

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

chanel1頻道

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

訂閱釋出

測試釋出、訂閱

十、主從複製

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

主從複製的作用：

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

十一、叢集搭建及小實驗

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

11.1、架構一：一主兩從

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

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

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

啟動三臺redis

讓16378、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.2、架構二

其中的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.3、架構三：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叢集中

更多更詳細的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出現集中式過期的情況

Java進階練習題整理（1）
2021-08-09
Java
【長文】帶你搞明白Redis
2024-06-20
Redis
Redis入門--進階詳解
2020-08-26
Redis
【資料庫】Redis進階篇
2019-05-08
資料庫Redis
Redis從入門到進階
2019-04-18
Redis
redis訂閱者和進階
2024-09-09
Redis
Redis進階知識一覽
2022-05-17
Redis
深度長文：NLP的巨人肩膀（上）
2018-12-10
iOS 模組化進階整理記錄
2018-04-11
iOS
讀懂深度學習，走進“深度學習+”階段
2023-01-13
深度學習
進階 Redis 技術與應用
2024-05-08
Redis
萬字長文深度剖析 RocketMQ 設計原理
2022-05-13
MQ
Apache Flink 進階入門（二）：Time 深度解析
2019-09-17
Apache
帶你深度解鎖Webpack系列(進階篇)
2020-03-09
Web
redis進階之快取管理(1課時)
2018-10-03
Redis快取
萬字長文深度剖析物件導向的javascript
2020-12-02
物件JavaScript
一文深度揭祕Redis的磁碟持久化機制
2019-10-12
Redis持久化
Redis 技術整理
2023-11-03
Redis
【進階之路】深入理解Java虛擬機器的類載入機制（長文）
2021-06-29
Java虛擬機
rodert單排學習redis進階【白銀一】
2020-06-25
Redis
十年技術進階路，讓我明白了三件要事（8000字長文）
2022-05-10
Android高階進階之路【四】一文讀懂 Handler 機制
2021-11-08
Android
長沙Java培訓：Java基礎通往高階進階篇
2021-11-18
Java
【進階篇】Redis實戰之Jedis使用技巧詳解
2022-12-29
Redis
Java開發工程師進階篇-深入淺出Redis
2021-09-14
Java工程師Redis
萬字長文概述NLP中的深度學習技術
2019-02-28
深度學習
【9k字+】第二篇：進階：掌握 Redis 的一些進階操作（Linux環境）
2021-01-26
RedisLinux
技術管理進階——成長加速的祕密
2022-02-22
理事長走進統信軟體，深度探討社群發展規劃 | 理事長走進系列
2023-11-13
Redis 高階特性 Redis Stream使用
2023-05-18
Redis
長文回顧和深度解析Supercell十年來的成就
2021-03-19
《深度學習進階：自然語言處理》中的網址
2020-08-11
深度學習自然語言處理
Redis高階特性
2020-09-30
Redis
redis高階部分
2024-10-30
Redis
Redis 的第 n 次涉及,我該整理整理了
2019-07-18
Redis
進階的Redis之雜湊分片原理與叢集實戰
2018-11-12
Redis
技術管理進階——關於成長的話題
2021-11-24
深度長文解析SpringWebFlux響應式框架15個核心元件原始碼
2024-07-04
SpringWebUX框架元件原始碼