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