高可用性（HA），原本是系統(tǒng)的一個特性，旨在確保在高于平均水平的時間內保持約定的運行性能水平，通常是正常運行時間。

Redis 作為一個內存數(shù)據(jù)庫，其數(shù)據(jù)通常存儲在內存中，一旦發(fā)生故障，可能導致數(shù)據(jù)丟失或服務中斷，避免單點故障至關重要，這樣系統(tǒng)才能順利快速地恢復。

Redis 高可用 是指 Redis 通過一系列技術手段確保在面臨故障的情況下也能持續(xù)提供服務的能力。

圖片

由于我們現(xiàn)在已經(jīng)進入了一個分布式系統(tǒng)，并且需要考慮許多錯誤，因此在這個拓撲結構中需要考慮一些新問題，以前簡單的事情現(xiàn)在變得更加復雜。

為了保證 Redis 的高可用，它主要采用了以下三種手段：

1. Redis 主從復制
2. Redis 哨兵模式
3. Redis 集群Cluster

接下來，我們逐個來分析看看。

1、Redis 主從復制

圖片

主從復制是 Redis 多機運行中最基礎的功能，它是把多個 Redis 節(jié)點組成一個 Redis 集群，在這個集群當中有一個主節(jié)點用來進行數(shù)據(jù)的操作，其他從節(jié)點用于同步主節(jié)點的內容，并且提供給客戶端進行數(shù)據(jù)查詢。

Redis 主從同步分為：

• 全量復制：首次數(shù)據(jù)同步時
• 增量復制：只需把主從庫網(wǎng)絡斷連期間主庫收到的命令，同步給從庫

注意：在2.8版本之前只有全量復制，而2.8版本后有全量和增量復制

1.1 全量復制

全量復制主要的實施流程，包括以下幾個方面：

• 建立主從關系

當我們啟動多個 Redis 實例的時候，它們相互之間就可以通過 replicaof（Redis 5.0 之前使用 slaveof）命令形成主庫和從庫的關系

/*
 * 主：實例 1（ip：172.168.0.1）
 * 從：實例 2（ip：172.168.0.2）
 * 在從庫上執(zhí)行以下命令
 */
replicaof 172.16.0.1 6379

• 全量復制過程

    1）主從庫間建立連接、協(xié)商同步

    從庫給主庫發(fā)送 psync 命令，表示要進行數(shù)據(jù)同步，主庫根據(jù)這個命令的參數(shù)來啟動復制。

psync 命令包含了主庫的 runID 和復制進度 offset 兩個參數(shù)：

• runID，是每個 Redis 實例啟動時都會自動生成的一個隨機 ID，用來唯一標記這個實例
• offset，此時設為 -1，表示第一次復制

    2）主庫將所有數(shù)據(jù)同步給從庫

    主庫執(zhí)行 bgsave 命令，生成 RDB 文件，接著將文件發(fā)給從庫。從庫接收到 RDB 文件后，會先清空當前數(shù)據(jù)庫，然后加載 RDB 文件。

    在主庫將數(shù)據(jù)同步給從庫的過程中，主庫不會被阻塞，仍然可以正常接收請求，否則，Redis 的服務就被中斷了。但是，這些請求中的寫操作并沒有記錄到剛剛生成的 RDB 文件中。為了保證主從庫的數(shù)據(jù)一致性，主庫會在內存中用專門的 replication buffer，記錄 RDB 文件生成后收到的所有寫操作。

    3）主庫會把第二階段執(zhí)行過程中新收到的寫命令，再發(fā)送給從庫

    當主庫完成 RDB 文件發(fā)送后，就會把此時 replication buffer 中的修改操作發(fā)給從庫，從庫再重新執(zhí)行這些操作。

1.2 增量復制

此功能在 Redis 2.8 版本才引入，主要為了控制主從復制的成本開銷。網(wǎng)絡斷了之后，主從庫會采用增量復制的方式繼續(xù)同步。

先來看一個概念： replication_backlog 復制積壓緩沖區(qū)。

此命令一方面會傳輸給從節(jié)點，另外還會記錄在這個復制積壓緩沖區(qū)里。Redis 使用一個環(huán)形緩沖區(qū)的結構保存最近的一些命令。在緩沖區(qū)中，對字節(jié)進行編號，這個編號在 Redis 中叫復制偏移量。

圖片

是否滿足增量同步的條件：

• 從節(jié)點 replid 和 主節(jié)點的 replid 相同
• 復制偏移量 offset 在復制積壓緩沖區(qū)的 backlog_off 和 offset 范圍之間。

2、Redis 哨兵模式

哨兵模式是redis高可用的實現(xiàn)方式之一，使用一個或者多個哨兵(Sentinel)實例組成的系統(tǒng)，對redis節(jié)點進行監(jiān)控，在主節(jié)點出現(xiàn)故障的情況下，能將從節(jié)點中的一個升級為主節(jié)點，進行故障轉義，保證系統(tǒng)的可用性。

圖片

2.1 哨兵實現(xiàn)了什么功能呢？

• 監(jiān)控（Monitoring）：確保主從實例是否運作正常
• 自動故障轉移（Automatic failover）：如果主實例不可用并且足夠多的（法定數(shù)量）節(jié)點同意這是真的，Sentinel 節(jié)點可以啟動故障轉移
• 配置提供者（Configuration provider）：客戶端在初始化時，通過連接哨兵來獲得當前Redis服務的主節(jié)點地址
• 通知（Notification）：哨兵可以將故障轉移的結果發(fā)送給客戶端

以這種方式使用 Redis Sentinel 可以進行故障檢測。此檢測涉及多個哨兵進程同意當前主實例不再可用。這個協(xié)議過程稱為 Quorum。這可以提高魯棒性并防止一臺機器行為異常導致無法訪問主 Redis 節(jié)點。

2.2 自動故障轉移

• 主觀下線

哨兵（Sentinel）節(jié)點會每秒一次的頻率向建立了命令連接的實例發(fā)送 PING 命令，如果在down-after-milliseconds 毫秒內沒有做出有效響應，包括（PONG/LOADING/MASTERDOWN）以外的響應，哨兵就會將該實例在本結構體中的狀態(tài)標記為 SRI_S_DOWN 主觀下線。

• 客觀下線

當一個哨兵節(jié)點發(fā)現(xiàn)主節(jié)點處于主觀下線狀態(tài)時，會向其他的哨兵節(jié)點發(fā)出詢問，該節(jié)點是不是已經(jīng)主觀下線了。

如果超過配置參數(shù) quorum 個節(jié)點認為是主觀下線時，該哨兵節(jié)點就會將自己維護的結構體中該主節(jié)點標記為 SRI_O_DOWN 客觀下線 詢問命令：

SENTINEL is-master-down-by-addr <current_epoch> <run_id>

• leader選舉

在認為主節(jié)點客觀下線的情況下，哨兵節(jié)點節(jié)點間會發(fā)起一次選舉，命令如下：

SENTINEL is-master-down-by-addr <current_epoch> <run_id>

只是這次會將自己的 run_id 帶進去，希望接受者將自己設置為主節(jié)點。

如果超過半數(shù)以上的節(jié)點返回將該節(jié)點標記為 leader 的情況下，會由該 leader 對故障進行轉移。

• 故障轉移

在從節(jié)點中挑選出新的主節(jié)點

a. 通訊正常

b. 優(yōu)先級排序

c. 優(yōu)先級相同是選擇offset最大的

將該節(jié)點設置成新的主節(jié)點 SLAVEOF no one,并確保在后續(xù)的INGO命令時，該節(jié)點返回狀態(tài)為master

將其他的從節(jié)點設置成從新的主節(jié)點復制, SLAVEOF命令

將舊的主節(jié)點變成新的主節(jié)點的從節(jié)點

3、Redis 集群Cluster

Cluster 即 集群模式。類似MySQL，Redis 集群也是一種分布式數(shù)據(jù)庫方案，集群通過分片（sharding）模式來對數(shù)據(jù)進行管理，并具備分片間數(shù)據(jù)復制、故障轉移和流量調度的能力。

圖片

Redis Cluster 允許 Redis 的水平擴展。

3.1 集群Cluster 介紹

Redis 集群將數(shù)據(jù)劃分為 16384（2的14次方）個哈希槽（slots），如果你有多個實例節(jié)點，那么每個實例節(jié)點將管理其中一部分的槽位，槽位的信息會存儲在各自所歸屬的節(jié)點中。以下圖為例，該集群有4個 Redis 節(jié)點，每個節(jié)點負責集群中的一部分數(shù)據(jù)，數(shù)據(jù)量可以不均勻。比如性能好的實例節(jié)點可以多分擔一些壓力。

圖片

一個Redis集群一共有16384個哈希槽，你可以有1 ~ n個節(jié)點來分配這些哈希槽，可以不均勻分配，每個節(jié)點可以處理0個 到至多 16384 個槽點。當16384個哈希槽都有節(jié)點進行管理的時候，集群處于online 狀態(tài)。同樣的，如果有一個哈希槽沒有被管理到，那么集群處于offline狀態(tài)。

上面圖中4個實例節(jié)點組成了一個集群，集群之間的信息通過 Gossip協(xié)議 進行交互，這樣就可以在某一節(jié)點記錄其他節(jié)點的哈希槽（slots）的分配情況。

3.2 Cluster模式擴展

單機的吞吐無法承受持續(xù)擴增的流量的時候，最好的辦法是從橫向（scale out） 和 縱向（scale up）兩方面進行擴展：

• 縱向擴展（scale up）：將單個實例的硬件資源做提升，比如 CPU核數(shù)量、內存容量、SSD容量
• 橫向擴展（scale out）：橫向擴增 Redis 實例數(shù)，這樣每個節(jié)點只負責一部分數(shù)據(jù)就可以（典型的分治思維）

圖片

4、總結

高可用一般來說有兩個含義：1）數(shù)據(jù)盡量不丟失，2）保證服務盡可能可用。

AOF 和 RDB 數(shù)據(jù)持久化保證了數(shù)據(jù)盡量不丟失，而多節(jié)點來保證服務盡可能提供服務。單個節(jié)點的系統(tǒng)吞吐量有限，容量也有限，缺點明顯，一旦發(fā)生故障會導致服務不可用。

• 使用讀寫分離之前，可以考慮其他方法增加Redis的讀負載能力：如盡量優(yōu)化主節(jié)點（減少慢查詢、減少持久化等其他情況帶來的阻塞等）提高負載能力；使用Redis集群同時提高讀負載能力和寫負載能力等
• 哨兵模式已經(jīng)實現(xiàn)了故障自動轉移的能力，但業(yè)務規(guī)模的不斷擴展，用戶量膨脹，并發(fā)量持續(xù)提升，會出現(xiàn)了 Redis 響應慢的情況
• 使用 Redis Cluster 集群，主要解決了大數(shù)據(jù)量存儲導致的各種慢問題，同時也便于橫向拓展。在面對千萬級甚至億級別的流量的時候，很多是在千百臺的實例節(jié)點組成的集群上進行流量調度、服務治理的。