Redis叢集一般有5種：
1，主從複製
#2，哨兵模式
3，Redis官方提供的Cluster叢集模式(服務端)
4，Jedis sharding叢集(客戶端sharding)
5,利用中間件代理，例如豌豆莢的codis等
#介紹完他們的模式，現在來分析他們的原理：
主從複製（Master-Slave Replication）:
實作主從複製（Master-Slave Replication）的工作原理：Slave從節點服務啟動並連接到Master之後，它將主動發送一個SYNC命令。 Master服務主節點收到同步指令後將啟動後台記憶體進程，同時收集所有接收到的用於修改資料集的指令，在背景處理程序執行完畢後，Master將傳送整個資料庫檔案到Slave，以完成一次完全同步。而Slave從節點服務在接收到資料庫檔案資料之後將其存檔並載入到記憶體中。此後，Master主節點繼續將所有已經收集到的修改命令，和新的修改命令依序傳送給Slaves，Slave將在本次執行這些資料修改命令，從而達到最終的資料同步。
如果Master和Slave之間的連結出現斷連現象，Slave可以自動重連Master，但是在連線成功之後，一次完全同步將會被自動執行。
主從複製設定
修改從節點的設定檔：slaveof masterip masterport
如果設定了密碼，就要設定：masterauth master- password
哨兵模式:
該模式是從Redis的2.6版本開始提供的，但是當時這個版本的模式是不穩定的，直到Redis的2.8版本以後，這個哨兵模式才穩定下來，無論是主從模式，還是哨兵模式，這兩個模式都有一個問題，不能水平擴容，並且這兩個模式的高可用特性都會受到Master主節點記憶體的限制。
Sentinel(哨兵)程序是用來監控redis叢集中Master主伺服器工作的狀態，在Master主伺服器發生故障的時候，可以實現Master和Slave伺服器的切換，確保系統的高可用。
Sentinel（哨兵）進程的作用
監控(Monitoring): 哨兵(sentinel) 會不斷檢查你的Master和Slave是否運作正常。
提醒(Notification)：當被監控的某個Redis節點出現問題時, 哨兵(sentinel) 可以透過 API 向管理員或其他應用程式發送通知。
自動故障遷移(Automatic failover)：當一個Master不能正常工作時，哨兵(sentinel) 會開始一次自動故障遷移操作，它會將失效Master的其中一個Slave升級為新的Master, 並讓失效Master的其他Slave改為複製新的Master；當客戶端試圖連接失效的Master時，叢集也會向客戶端傳回新Master的位址，使得叢集可以使用現在的Master替換失效Master。 Master和Slave伺服器切換後，Master的redis.conf、Slave的redis.conf和sentinel.conf的設定檔的內容都會發生對應的改變，即，Master主伺服器的redis.conf設定檔中會多一行slaveof的配置，sentinel.conf的監控目標會隨之調換。
Sentinel（哨兵）程序的工作方式
每個Sentinel（哨兵）程序以每秒鐘一次的頻率向整個集群中的Master主伺服器，Slave從伺服器以及其他Sentinel（哨兵）進程發送一個PING 命令。
如果一個實例（instance）距離最後一次有效回覆PING 指令的時間超過down-after-milliseconds 選項所指定的值， 則這個實例會被Sentinel（哨兵）程序標記為主觀下線（SDOWN )
如果一個Master主伺服器被標記為主觀下線（SDOWN），則正在監視這個Master主伺服器的所有Sentinel（哨兵）進程要以每秒一次的頻率確認Master主伺服器的確進入了主觀下線狀態
當有足夠數量的Sentinel（哨兵）程序（大於等於設定檔指定的值）在指定的時間範圍內確認Master主伺服器進入了主觀下線狀態（SDOWN）， 則Master主伺服器會被標記為客觀下線（ODOWN）
在一般情況下， 每個Sentinel（哨兵）程序會以每10 秒一次的頻率向集群中的所有Master主伺服器、Slave從伺服器發送INFO 命令。
當Master主伺服器被Sentinel（哨兵）程序標記為客觀下線（ODOWN）時，Sentinel（哨兵）進程向下線的Master主伺服器的所有Slave從伺服器發送INFO 指令的頻率會從10 秒一次改為每秒一次。
若沒有足夠數量的 Sentinel（哨兵）程序同意 Master主伺服器下線， Master主伺服器的客觀下線狀態就會被移除。若 Master主伺服器重新向 Sentinel（哨兵）程序發送 PING 指令返回有效回复，Master主伺服器的主觀下線狀態就會移除。
Redis官方 Cluster叢集模式
Redis Cluster是一種伺服器Sharding技術，3.0版本開始正式提供。
在這個圖中，每一個藍色的圈都代表著一個redis的伺服器節點。它們任何兩個節點之間都是相互連通的。客戶端可以與任何一個節點連接，然後就可以存取叢集中的任何一個節點。對其進行訪問和其他操作。
Redis叢集資料分片
在redis的每一個節點上，都有這麼兩個東西，一個是插槽（slot）可以理解為是一個可以儲存兩個數值的一個變數這個變數的取值範圍是：0-16383。還有一個是cluster我個人把這個cluster理解為是一個叢集管理的插件。當我們的訪問的key到達的時候，redis會根據crc16的演算法得出一個結果，然後把結果對16384 求餘數，這樣每個key 都會對應一個編號在0-16383 之間的哈希槽，通過這個值，去找到對應的插槽所對應的節點，然後直接自動跳到這個對應的節點上進行訪問操作。
Jedis sharding集群
Redis Sharding可以說是在Redis cluster出來之前業界普遍的採用方式，其主要思想是採用hash演算法將儲存資料的key進行hash散列，這樣特定的key會被定為到特定的節點上。
慶幸的是，Java Redis客戶端驅動Jedis已支援Redis Sharding功能，即ShardedJedis以及結合快取池的ShardedJedisPool
Jedis的Redis Sharding實作具有以下特點：
#採用一致性雜湊演算法，將key和節點name同時hashing，然後進行映射匹配，採用的演算法是MURMUR_HASH。採用一致性雜湊而不是採用簡單類似哈希求模映射的主要原因是當增加或減少節點時，不會產生由於重新匹配造成的rehashing。一致性雜湊只影響相鄰節點key分配，影響量小。
為了避免一致性雜湊只會影響相鄰節點造成節點分配壓力，ShardedJedis會對每個Redis節點根據名字(沒有，Jedis會賦予缺省名字)會虛擬化出160個虛擬節點進行散列。根據權重weight，也可虛擬化出160倍數的虛擬節點。用虛擬節點做映射匹配，可以在增加或減少Redis節點時，key在各Redis節點移動再分配更均勻，而不是只有相鄰節點受影響。
ShardedJedis支持keyTagPattern模式，即抽取key的一部分keyTag做sharding，這樣透過合理命名key，可以將一組相關聯的key放入同一個Redis節點，這在避免跨節點存取相關資料時很重要。
利用中間件代理
中間件的作用是將我們需要存入redis中的資料的key透過一套演算法計算得出一個值。然後根據這個值找到對應的redis節點，將這些資料存在這個redis的節點中。
常用的中間件有這幾種
Twemproxy
Codis
nginx
以上是redis有哪些叢集模式的詳細內容。更多資訊請關注PHP中文網其他相關文章！
