Redis 知識總結_ZenDei技術網路在線

Redis 和 memcache 的區別，Redis 支持的數據類型應用場景 redis 支持的數據結構更豐富(string，hash，list，set，zset)。memcache 只支持 key-value 的存儲； redis 原生支持集群，memcache 沒有原生的集群模式。 ...

1. Redis 概覽

Redis 和 memcache 的區別，Redis 支持的數據類型應用場景

redis 支持的數據結構更豐富(string，hash，list，set，zset)。memcache 只支持 key-value 的存儲；
redis 原生支持集群，memcache 沒有原生的集群模式。

2. Redis 單線程模型

redis 單線程處理請求流程

redis 採用 IO 多路復用機制來處理請求，採用 reactor IO 模型，處理流程如下:

首先接收到客戶端的 socket 請求，多路復用器將 socket 轉給連接應答處理器；
連接應答處理器將 AE_READABLE 事件與命令請求處理器關聯(這裡是把 socket 事件放入一個隊列)；
命令請求處理器從 socket 中讀到指令，再記憶體中執行，並將 AE_WRITEABLE 事件與命令回覆處理器關聯；
命令回覆處理器將結果返回給 socket，並解除關聯。

redis 單線程效率高的原因

非阻塞 IO 復用(上圖流程)， I/O 多路復用分派事件，事件處理器處理事件(這個可以理解為註冊的一段函數，定義了事件發生的時候應該執行的動作)，這裡分派事件和處理事件其實都是同一個線程；
純記憶體操作效率高；
單線程反而避免了多線程切換。

3. Redis 過期策略

對 key 設置有效期，redis 的刪除策略: 定期刪除+惰性刪除。

定期刪除指的是 redis 預設每 100ms 就隨機抽取一些設置了過期事件的 key ，檢查是否過期，如果過期就刪除。如果 redis 設置了 10 萬個 key 都設置了過期時間，每隔幾百毫秒就要檢查 10 萬個 key 那 CPU 負載就很高了，所以 redis 並不會每隔 100ms 就檢查所有的 key，而是隨機抽取一些 key 來檢查。
但這樣會導致有些 key 過期了並沒有被刪除，所以採取了惰性刪除。意思是在獲取某個 key 的時候發現過期了，如果 key 過期了就刪除掉不會返回。

這兩個策略結合起來保證過期的 key 一定會被刪除。

最大記憶體淘汰(maxmemory-policy)

如果 redis 記憶體占用太多，就會進行記憶體淘汰。有如下策略:

noeviction: 如果記憶體不足以寫入數據，新寫入操作直接報錯；
allkeys-lru: 記憶體不足以寫入數據，移除最近最少使用的 key(最常用的策略)；
allkeys-random: 記憶體不足隨機移除幾個 key；
volatile-lru: 在設置了過期時間的 key 中，移除最近最少使用；
volatile-random: 設置了過期的時間的 key 中，隨機移除幾個。

4. Redis 主從模式保證高併發和高可用(哨兵模式)

讀寫分離

單機的 Redis 的 QPS 大概就在上萬到幾萬不等，無法承受更高的併發。

讀寫分離保證高併發(10W+ QPS)：對於緩存來說一般都是支撐高併發讀，寫請求都是比較少的。採用讀寫分離的架構(一主多從)，master 負責接收寫請求，數據同步到 slave 上提供讀服務，如果遇到瓶頸只需要增加 slave 機器就可以水平擴容

主從複製機制

redis replication 機制：

redis 採取非同步複製到 slave 節點；
slave 節點做複製操作的時候是不會 block 自己的，它會使用舊的數據集來提供服務，複製。完成後，刪除舊的數據集，載入新的數據集，這個時候會暫停服務(時間很短暫)；
如果採用了主從架構，master 需要開啟持久化。如果 master 沒有開啟持久化(rdb 和 aof 都關閉了)。master 宕機重啟後數據是空的，然後經過複製就把所有 slave 的數據也弄丟了。

即使採用高可用的的哨兵機制，可能 sentinal 還沒有檢測到 master failure，master 就自動重啟了，還是會導致 slave 清空故障。

主從同步流程

當 slave 啟動時會發送一個 psync 命令給 master；
如果是重新連接 master，則 master node 會複製給 slave 缺少的那部分數據；
如果是 slave 第一次連接 master，則會觸發一次全量複製(full resynchronization)。開始 full resynchronization 的時候，master 會生成一份 rdb 快照，同時將客戶端命令緩存在記憶體，rdb 生成完後，就發送給 slave，slave 先寫入磁碟在載入到記憶體。然後 master 將緩存的命令發送給 slave。

哨兵(sentinal)模式介紹

哨兵是 redis 集群架構的一個重要組件，主要提供如下功能：

集群監控：負責監控 master 和 slave 是否正常工作；
消息通知：如果某個 redis 實例有故障，哨兵負責發消息通知管理員；
故障轉移: 如果 master node 發生故障，會自動切換到 slave；
配置中心：如果故障轉移發生了，通知客戶端新的 master 地址。

哨兵的核心知識:

哨兵至少三個，保證自己的高可用；
哨兵+主從的部署架構是用來保證 redis 集群高可用的，並非保證數據不丟失；
哨兵(Sentinel)需要通過不斷的測試和觀察才能保證高可用。

為什麼哨兵只有兩個節點無法正常工作

假設哨兵集群只部署了 2 個哨兵實例，quorum=1。

master 宕機的時候，s1 和 s2 只要有一個哨兵認為 master 宕機 j 就可以進行切換，並且會從 s1 和 s2 中選取一個來進行故障轉移。這個時候是需要滿足 majority，也就是大多數哨兵是運行的，2 個哨兵的 majority 是 2，如果 2 個哨兵都運行著就允許執行故障轉移。如果 M1 所在的機器宕機了，那麼 s1 哨兵也就掛了，只剩 s2 一個，沒有 majorityl 來允許執行故障轉移，雖然集群還有一臺機器 R1，但是故障轉移也不會執行。

如果是經典的三哨兵集群，如下:

此時 majority 也是 2，就算 M1 所在的機器宕機了，哨兵還是剩下兩個 s2 和 s3，它們滿足 majority 就可以允許故障轉移執行。

哨兵核心底層原理

sdown 和 odown 兩種失敗狀態；

sdown 是主觀宕機，就是一個哨兵覺得 master 宕機了，達成條件是如果一個哨兵 ping master 超過了 is-master-down-after-milliseconds 指定的毫秒數後就認為主觀宕機；
odown 是客觀宕機，如果一個哨兵在指定時間內收到了 majority(大多數) 數量的哨兵也認為那個 master 宕機了，就是客觀宕機。

哨兵之間的互相發現：哨兵是通過 redis 的 pub/sub 實現的。

5. Redis 數據的恢復(Redis 的持久化)

RDB

RDB 原理

RDB（Redis DataBase）是將某一個時刻的記憶體快照（Snapshot），以二進位的方式寫入磁碟的過程。

RDB 有兩種方式 save 和 bgsave:

save: 執行就會觸發 Redis 的持久化，但同時也是使 Redis 處於阻塞狀態，直到 RDB 持久化完成，才會響應其他客戶端發來的命令；
bgsave: bgsave 會 fork() 一個子進程來執行持久化，整個過程中只有在 fork() 子進程時有短暫的阻塞，當子進程被創建之後，Redis 的主進程就可以響應其他客戶端的請求了。

RDB 配置

除了使用 save 和 bgsave 命令觸發之外， RDB 支持自動觸發。

自動觸發策略可配置 Redis 在指定的時間內，數據發生了多少次變化時，會自動執行 bgsave 命令。在 redis 配置文件中配置:

在時間 m 秒內，如果 Redis 數據至少發生了 n 次變化，那麼就自動執行BGSAVE命令。
save m n

RDB 優缺點

RDB 的優點:

RDB 會定時生成多個數據文件，每個數據文件都代表了某個時刻的 redis 全量數據，適合做冷備，可以將這個文件上傳到一個遠程的安全存儲中，以預定好的策略來定期備份 redis 中的數據；
RDB 對 redis 對外提供讀寫服務的影響非常小，redis 是通過 fork 主進程的一個子進程操作磁碟 IO 來進行持久化的；
相對於 AOF，直接基於 RDB 來恢復 reids 數據更快。

RDB 的缺點:

如果使用 RDB 來恢複數據，會丟失一部分數據，因為 RDB 是定時生成的快照文件；
RDB 每次來 fork 出子進程的時候，如果數據文件特別大，可能會影響對外提供服務，暫停數秒(主進程需要拷貝自己的記憶體表給子進程，實例很大的時候這個拷貝過程會很長)。latest_fork_usec 代表 fork 導致的延時；Redis 上執行 INFO 命令查看 latest_fork_usec；當 RDB 比較大的時候，應該在 slave 節點執行備份，併在低峰期執行。

AOF

AOF 原理

redis 對每條寫入命令進行日誌記錄，以 append-only 的方式寫入一個日誌文件，redis 重啟的時候通過重放日誌文件來恢複數據集。(由於運行久了 AOF 文件會越來越大，redis 提供一種 rewrite 機制，基於當前記憶體中的數據集，來構建一個更小的 AOF 文件，將舊的龐大的 AOF 文件刪除)。rewrite 即把日誌文件壓縮，通過 bgrewriteaof 觸發重寫。AOF rewrite 後臺執行的方式和 RDB 有類似的地方，fork 一個子進程，主進程仍進行服務，子進程執行 AOF 持久化，數據被 dump 到磁碟上。與 RDB 不同的是，後臺子進程持久化過程中，主進程會記錄期間的所有數據變更（主進程還在服務），並存儲在 server.aof_rewrite_buf_blocks 中；後臺子進程結束後，Redis 更新緩存追加到 AOF 文件中，是 RDB 持久化所不具備的。

AOF 的工作流程如下:

Redis 執行寫命令後，把這個命令寫入到 AOF 文件記憶體中（write 系統調用）；
Redis 根據配置的 AOF 刷盤策略，把 AOF 記憶體數據刷到磁碟上（fsync 系統調用）；
根據 rewrite 相關的配置觸發 rewrite 流程。

AOF 配置

appendonly: 是否啟用 AOF(yes | no)；
appendfsync: 刷盤的機制：

always：主線程每次執行寫操作後立即刷盤，此方案會占用比較大的磁碟 IO 資源，但數據安全性最高；
everysec：主線程每次寫操作只寫記憶體就返回，然後由後臺線程每隔 1 秒執行一次刷盤操作（觸發 fsync 系統調用），此方案對性能影響相對較小，但當 Redis 宕機時會丟失 1 秒的數據；
no：主線程每次寫操作只寫記憶體就返回，記憶體數據什麼時候刷到磁碟，交由操作系統決定，此方案對性能影響最小，但數據安全性也最低，Redis 宕機時丟失的數據取決於操作系統刷盤時機。

auto-aof-rewrite-percentage: 當 aof 文件相較於上一版本的 aof 文件大小的百分比達到多少時觸發 AOF 重寫。舉個例子，auto-aof-rewrite-percentage 選項配置為 100，上一版本的 aof 文件大小為 100M，那麼當我們的 aof 文件達到 200M 的時候，觸發 AOF 重寫；
auto-aof-rewite-min-size：最小能容忍 aof 文件大小，超過這個大小必須進行 AOF 重寫；
no-appendfsync-on-rewrite: 設置為 yes 表示 rewrite 期間對新寫操作不 fsync，暫時存在記憶體中，等 rewrite 完成後再寫入，預設為 no。

AOF 優缺點

AOF 的優點:

可以更好的保證數據不丟失，一般 AOF 每隔 1s 通過一個後臺線程來執行 fsync(強制刷新磁碟頁緩存)，最多丟失 1s 的數據；
AOF 以 append-only 的方式寫入(順序追加)，沒有磁碟定址開銷，性能很高；
AOF 即使文件很大，觸發後臺 rewrite 的操作的時候一般也不會影響客戶端的讀寫，(rewrite 的時候會對其中指令進行壓縮，創建出一份恢復需要的最小日誌出來)。

在創建新的日誌文件的時候，老的文件還是照常寫入，當新的文件創建完成後再交換新老日誌。但是還是有可能會影響到主線程的寫入，如：

當磁碟的 IO 負載很高，那這個後臺線程在執行 AOF fsync 刷盤操作（fsync 系統調用）時就會被阻塞住，，緊接著，主線程又需要把數據寫到文件記憶體中（write 系統調用），但此時的後臺子線程由於磁碟負載過高，導致 fsync 發生阻塞，遲遲不能返回，那主線程在執行 write 系統調用時，也會被阻塞住，直到後臺線程 fsync 執行完成後，主線程執行 write 才能成功返回。這時候主線程就無法響應客戶端的請求，可能會導致客戶端請求 redis 超時。具體類似: https://blog.csdn.net/mmgithub123/article/details/124507846。

AOF 日誌文件通過非常可讀的方式進行記錄，這個特性適合做災難性的誤操作的緊急恢復，比如不小心使用 flushall 清空了所有數據，只要 rewrite 沒有發生，就可以立即拷貝 AOF，將最後一條 flushall 命令刪除，再回放 AOF 恢複數據。

AOF 的缺點：

同一份數據，因為 AOF 記錄的命令會比 RDB 快照文件更大；
AOF 開啟後，支持寫的 QPS 會比 RDB 支持寫的 QPS 要低，畢竟 AOF 有寫磁碟的操作。

總結

總結 AOF 和 RDB 該如何選擇：兩者綜合使用，將 AOF 配置成每秒 fsync 一次。RDB 作為冷備，AOF 用來保證數據不丟失的恢復第一選擇，當 AOF 文件損壞或不可用的時候還可以使用 RDB 來快速恢復。

6. Redis 集群模式(redis cluster)

在主從部署模式上，雖然實現了一定程度的高併發，並保證了高可用，但是有如下限制:

master 數據和 slave 數據一模一樣，master 的數據量就是集群的限制瓶頸；
redis 集群的寫能力也受到了 master 節點的單機限制。

在高版本的 Redis 已經原生支持集群(cluster)模式，可以多 master 多 slave 部署，橫向擴展 Redis 集群的能力。Redis Cluster 支持 N 個 master node ，每個 master node 可以掛載多個 slave node。

redis cluster 介紹

自動將數據切片，每個 master 上放一部分數據；
提供內置的高可用支持，部分 master 不可用時還是能夠工作；
redis cluster 模式下，每個 redis 要開放兩個埠：6379 和 10000+以後的埠(如 16379)。16379 是用來節點之間通信的，使用的是 cluster bus 集群匯流排。cluster bus 用來做故障檢測，配置更新，故障轉移授權。

redis cluster 負載均衡

redis cluster 採用一致性 hash+虛擬節點來負載均衡。redis cluster 有固定的 16384 個 slot (2^14)，對每個 key 做 CRC16 值計算，然後對 16384 mod。可以獲取每個 key 的 slot。redis cluster 每個 master 都會持有部分 slot，比如三個 master 那麼每個 master 就會持有 5000 多個 slot。hash slot 讓 node 的添加和刪除變得很簡單，增加一個 master，就將其他 master 的 slot 移動部分過去，減少一個就分給其他 master，這樣讓集群擴容的成本變得很低。

cluster 基礎通信原理(gossip 協議)

與集中式不同(如使用 zookeeper 進行分散式協調註冊)，redis cluster 使用的是 gossip 協議進行通信。並不是將集群元數據存儲在某個節點上，而是不斷的互相通信，保持整個集群的元數據是完整的。gossip 協議所有節點都持有一份元數據，不同節點的元數據發生了變更，就不斷的將元數據發送給其他節點，讓其他節點也進行元數據的變更。

集中式的好處：元數據的讀取和更新時效性很好，一旦元數據變化就更新到集中式存儲，缺點就是元數據都在一個地方，可能導致元數據的存儲壓力。

對於 gossip 來說：元數據的更新會有延時，會降低元數據的壓力，缺點是操作是元數據更新可能會導致集群的操作有一些滯後。

redis cluster 主備切換與高可用

判斷節點宕機：如果有一個節點認為另外一個節點宕機，那就是 pfail，主觀宕機。如果多個節點認為一個節點宕機，那就是 fail，客觀宕機。跟哨兵的原理一樣；
對宕機的 master，從其所有的 slave 中選取一個切換成 master node，再次之前會進行一次過濾，檢查每個 slave 與 master 的斷開時間，如果超過了 cluster-node-timeout * cluster-slave-validity-factor 就沒有資格切換成 master；
從節點選取：每個從節點都會根據從 master 複製數據的 offset，來設置一個選舉時間，offset 越大的從節點，選舉時間越靠前，master node 開始給 slave 選舉投票，如果大部分 master(n/2+1)都投給了某個 slave，那麼選舉通過(與 zk 有點像，選舉時間類似於 epochid)；
整個流程與哨兵類似，可以說 redis cluster 集成了哨兵的功能，更加的強大；
Redis 集群部署相關問題 redis 機器的配置，多少台機器，能達到多少 qps?

機器標準:8 核+32G
集群: 5 主+5 從(每個 master 都掛一個 slave)
效果: 每台機器最高峰每秒大概 5W，5 台機器最多就是 25W，每個 master 都有一個從節點，任何一個節點掛了都有備份可切換成主節點進行故障轉移

腦裂問題哨兵模式下:

master 下掛載了 3 個 slave，如果 master 由於網路抖動被哨兵認為宕機了，執行了故障轉移，從 slave 裡面選取了一個作為新的 master，這個時候老的 master 又恢復了，剛好又有 client 連的還是老的 master，就會產生腦裂，數據也會不一致，比如 incr 全局 id 也會重覆。
redis 對此的解決方案是：min-slaves-to-write 1 至少有一個 slave 連接 min-slaves-max-lag 10 slave 與 master 主從複製延遲時間如果連接到 master 的 slave 數小於最少 slave 的數量，並且主從複製延遲時間超過配置時間，master 就拒絕寫入 12。client 連接 redis 多 tcp 連接的考量首先 redis server 雖然是單線程來處理請求，但是他是多路復用的，單 tcp 連接肯定是沒有多 tcp 連接性能好，多路復用一個 io 周期得到的就緒 io 事件越多，處理的就越多。這也不是絕對的，如果使用 pipeline 的方式傳輸，單連接會比多連接性能好，因為每一個 pipeline 的單次請求過多也會導致單周期到的命令太多，性能下降多少個連接比較合適這個問題， redis cluser 控制在每個節點 100 個連接以內。

作者：leobhao

本文來自博客園，作者：古道輕風，轉載請註明原文鏈接：https://www.cnblogs.com/88223100/p/Summary-of-Redis-knowledge.html