【README】

轉自： https://segmentfault.com/a/1190000022808576??? （好文章）

Redis 支持三種集群方案

• 主從復制模式
• Sentinel（哨兵）模式
• Cluster 模式

?

【1】主從復制模式?

主從復制的作用

通過持久化功能，Redis保證了即使在服務器重啟的情況下也不會丟失（或少量丟失）數據，因為持久化會把內存中數據保存到硬盤上，重啟會從硬盤上加載數據。 但是由于數據是存儲在一臺服務器上的，如果這臺服務器出現硬盤故障等問題，也會導致數據丟失。

為了避免單點故障，通常的做法是將數據庫復制多個副本以部署在不同的服務器上，這樣即使有一臺服務器出現故障，其他服務器依然可以繼續提供服務。

為此，?Redis 提供了復制（replication）功能，可以實現當一臺數據庫中的數據更新后，自動將更新的數據同步到其他數據庫上。

在復制的概念中，數據庫分為兩類，一類是主數據庫（master），另一類是從數據庫(slave）。主數據庫可以進行讀寫操作，當寫操作導致數據變化時會自動將數據同步給從數據庫。而從數據庫一般是只讀的，并接受主數據庫同步過來的數據。一個主數據庫可以擁有多個從數據庫，而一個從數據庫只能擁有一個主數據庫。

總結：引入主從復制機制的目的有兩個

• 一個是讀寫分離，分擔 "master" 的讀寫壓力
• 一個是方便做容災恢復

?

主從復制原理

• 從數據庫啟動成功后，連接主數據庫，發送 SYNC 命令；
• 主數據庫接收到 SYNC 命令后，開始執行 BGSAVE 命令生成 RDB 文件并使用緩沖區記錄此后執行的所有寫命令；
• 主數據庫 BGSAVE 執行完后，向所有從數據庫發送快照文件，并在發送期間繼續記錄被執行的寫命令；
• 從數據庫收到快照文件后丟棄所有舊數據，載入收到的快照；
• 主數據庫快照發送完畢后開始向從數據庫發送緩沖區中的寫命令；
• 從數據庫完成對快照的載入，開始接收命令請求，并執行來自主數據庫緩沖區的寫命令；（從數據庫初始化完成）
• 主數據庫每執行一個寫命令就會向從數據庫發送相同的寫命令，從數據庫接收并執行收到的寫命令（從數據庫初始化完成后的操作）
• 出現斷開重連后，2.8之后的版本會將斷線期間的命令傳給重數據庫，增量復制。
• 主從剛剛連接的時候，進行全量同步；全同步結束后，進行增量同步。當然，如果有需要，slave 在任何時候都可以發起全量同步。Redis 的策略是，無論如何，首先會嘗試進行增量同步，如不成功，要求從機進行全量同步。
• ?

主從復制優缺點

【主從復制優點】支持主從復制，主機會自動將數據同步到從機，可以進行讀寫分離； 為了分載 Master 的讀操作壓力，Slave 服務器可以為客戶端提供只讀操作的服務，寫服務仍然必須由Master來完成； Slave 同樣可以接受其它 Slaves 的連接和同步請求，這樣可以有效的分載 Master 的同步壓力； Master Server 是以非阻塞的方式為 Slaves 提供服務。所以在 Master-Slave 同步期間，客戶端仍然可以提交查詢或修改請求； Slave Server 同樣是以非阻塞的方式完成數據同步。在同步期間，如果有客戶端提交查詢請求，Redis則返回同步之前的數據；【主從復制缺點】Redis不具備自動容錯和恢復功能，主機從機的宕機都會導致前端部分讀寫請求失敗，需要等待機器重啟或者手動切換前端的IP才能恢復（也就是要人工介入）； 主機宕機，宕機前有部分數據未能及時同步到從機，切換IP后還會引入數據不一致的問題，降低了系統的可用性； 如果多個 Slave 斷線了，需要重啟的時候，盡量不要在同一時間段進行重啟。因為只要 Slave 啟動，就會發送sync 請求和主機全量同步，當多個 Slave 重啟的時候，可能會導致 Master IO 劇增從而宕機。 Redis 較難支持在線擴容，在集群容量達到上限時在線擴容會變得很復雜；

【2】哨兵模式?

1）哨兵模式是什么？ 啟動一個線程作為哨兵監控 redis節點是否宕機，若有宕機，則做進一步處理；

2）哨兵模式為什么要引入？ 由于主從復制模式下的redis集群，當 master宕機時，無法自動把 slave節點切換為 master節點； 哨兵模式就是解決自動切換slave節點為master，而引入的；

3）怎么啟動哨兵模式集群？ 簡單，這里不再累述；

4）哨兵模式原理

5）哨兵模式優缺點

哨兵模式的優缺點 【優點】 哨兵模式是基于主從模式的，所有主從的優點，哨兵模式都具有。 主從可以自動切換，系統更健壯，可用性更高(可以看作自動版的主從復制)。【缺點】 Redis較難支持在線擴容，在集群容量達到上限時在線擴容會變得很復雜。

【3】cluster模式（分片存儲）

1）cluster模式的redis集群是什么？

Redis 的哨兵模式基本已經可以實現高可用，讀寫分離 ，但是在這種模式下每臺 Redis 服務器都存儲相同的數據，很浪費內存，所以在 redis3.0上加入了 Cluster 集群模式，實現了 Redis 的分布式存儲，也就是說每臺 Redis 節點上存儲不同的內容。

補充： cluster模式的redis集群讀寫原理；

在這個圖中，每一個藍色的圈都代表著一個 redis 的服務器節點。它們任何兩個節點之間都是相互連通的。客戶端可以與任何一個節點相連接，然后就可以訪問集群中的任何一個節點。對其進行存取和其他操作。

【荔枝】分布式存儲

k1 存儲在 203:6379 master節點，如下；

192.168.163.201:6379> set k1 v021801 -> Redirected to slot [12706] located at 192.168.163.203:6379 OK 192.168.163.203:6379> get k1 "v021801" 192.168.163.203:6379> keys * 1) "k1" 192.168.163.203:6379> get k1 "v021801"

又 203:6379? 201:6379?? 202:6379 這3個節點屬于同一個集群中的master節點，只不過存儲不同的分片或槽；

但當客戶端連接 201:6379? 202:6379 節點時，同樣可以獲取到 k1的值，即便其沒有存儲在 201:6379? 202:6379節點上； 這就是集群的魅力所在；

[root@centos201 bin]# redis-cli -h 192.168.163.201 -p 6379 -c 192.168.163.201:6379> keys * (empty list or set) 192.168.163.201:6379> get k1 -> Redirected to slot [12706] located at 192.168.163.203:6379 "v021801" 192.168.163.203:6379> exit [root@centos201 bin]# [root@centos201 bin]# redis-cli -h 192.168.163.202 -p 6379 -c 192.168.163.202:6379> keys * (empty list or set) 192.168.163.202:6379> get k1 -> Redirected to slot [12706] located at 192.168.163.203:6379 "v021801"

2）為什么要引入？分片存儲，擴容； 且支持在線擴容；且擴容非常簡單；

【集群的數據分片】
Redis 集群沒有使用一致性 hash，而是引入了哈希槽【hash slot】的概念。

Redis 集群有16384 個哈希槽，每個 key 通過 CRC16 校驗后對 16384 取模來決定放置哪個槽。集群的每個節點負責一部分hash槽，舉個例子，比如當前集群有3個節點，那么：

節點 A 包含 0 到 5460 號哈希槽
節點 B 包含 5461 到 10922 號哈希槽
節點 C 包含 10923 到 16383 號哈希槽
這種結構很容易添加或者刪除節點。比如如果我想新添加個節點 D ， 我需要從節點 A， B， C 中得部分槽到 D 上。如果我想移除節點 A ，需要將 A 中的槽移到 B 和 C 節點上，然后將沒有任何槽的 A 節點從集群中移除即可。由于從一個節點將哈希槽移動到另一個節點并不會停止服務，所以無論添加刪除或者改變某個節點的哈希槽的數量都不會造成集群不可用的狀態。

在 Redis 的每一個節點上，都有這么兩個東西（插槽+節點），一個是插槽（slot），它的的取值范圍是：0-16383。還有一個就是 cluster，可以理解為是一個集群管理的插件。當我們的存取的 Key到達的時候，Redis 會根據 CRC16 的算法得出一個結果，然后把結果對 16384 求余數，這樣每個 key 都會對應一個編號在 0-16383 之間的哈希槽，通過這個值，去找到對應的插槽所對應的節點，然后直接自動跳轉到這個對應的節點上進行存取操作。

?

3）Redis 集群的主從復制模型?

為了保證高可用，redis-cluster集群引入了主從復制模型，一個主節點對應一個或者多個從節點，當主節點宕機的時候，就會啟用從節點。當其它主節點 ping 一個主節點 A 時，如果半數以上的主節點與 A 通信超時，那么認為主節點 A 宕機了。如果主節點 A 和它的從節點 A1 都宕機了，那么該集群就無法再提供服務了。

4）redis集群特點

所有的 redis 節點彼此互聯(PING-PONG機制)，內部使用二進制協議優化傳輸速度和帶寬。 節點的 fail 是通過集群中超過半數的節點檢測失效時才生效。 客戶端與 Redis 節點直連，不需要中間代理層.客戶端不需要連接集群所有節點，連接集群中任何一個可用節點即可。

?

?

?

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的redis集群3种模式的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。