1.簡介
Redis在生產環境中一般是通過集群的方式進行運行，Redis集群包括主從復制集群和數據分片集群兩種類型。
*主從復制集群提供高可用性，而數據分片集群提供負載均衡。
*數據分片集群中能實現主從復制集群的功能。
2.Redis主從復制集群
主從復制集群中由Master節點提供讀寫服務，Slave節點負責同步Master節點中的數據，當Master節點發生故障時，由Slave節點充當Master對外提供服務。
主從復制集群中可以使用一主一從模式，也可以使用一主多從模式，在一主多從模式中主節點需要將修改同步給各個從節點從而增加了主節點的壓力（帶寬）
*在主從復制集群中Slave節點能夠進行讀取（不建議），但如果沒有開啟TCP的NO_DELAY功能，那么讀取的數據可能是臟數據，在Slave節點進行寫入時，會提示Slave節點不能進行寫入。
關於讀寫分離
應用對於數據庫而言都是讀多寫少的，即數據庫的讀取壓力要比寫入的壓力大（即100個請求95個都是讀的），由於受數據庫自身性能影響，因此一般都會搭建主從數據庫，由多個從數據庫提供讀取服務，分擔壓力，實現讀寫分離。
讀寫分離是相對於有磁盤IO操作的數據庫而言的，對於基於內存的NoSQL來說不存在此問題，其讀取和寫入的性能都很快，每秒能處理幾萬個請求，因此沒有必要進行讀寫分離，Redis中應用主從復制集群是為了保障集群的高可用性，當Master節點發生故障時，由Slave節點充當Master對外提供服務。
主從數據庫實現讀寫分離的根本原因是數據庫自身性能低下。
2.1 搭建主從復制集群
直接修改各個節點的redis.conf配置文件
#Slave節點同步Master節點中的數據
slaveof <master> <port>
#Slave節點修改為只讀模式
slave-read-only=yes
*當Master節點啟動后再啟動所有的Slave節點。
*當主從復制集群搭建后可以通過info replication命令查看集群間的信息。
2.2 主從復制集群中的數據同步
主從復制集群中的數據同步使用PSYNC命令進行完成，PSYNC命令包含全量復制以及部分復制。
1.全量復制：首次加入集群的Slave節點會同步Master節點中的所有數據。
2.部分復制：再次與Master節點建立連接的Slave節點同步Master節點中的部分數據。
*Redis提供了repl-disable-tcp-nodelay命令，表示是否啟用TCP的NO_DELAY功能，當該命令為yes時，表示禁用TCP的NO_DELAY功能，那么Master節點在同步修改給各個Slave節點時會合並小的TCP包從而節省帶寬，但此方式會增加同步延時(40ms左右)，當該命令為no時，表示啟用TCP的NO_DELAY功能，那么Master節點能夠實時的同步修改給各個Slave節點。
2.3 主從復制集群中的故障轉移
當Master節點發生故障時，可以通過手動或者自動的方式進行故障轉移
手動故障轉移
1.將其中一個存活的Slave節點斷開與Master節點的連接，並使其成為新的Master節點（slaveof no one）
2.將其他的Slave節點與該新的Master節點建立連接（slaveof ip port）
3.修改各個節點的redis.conf配置文件，更新主從映射關系，保證下次重啟時使用最新的主從關系啟動，避免主從數據不一致問題。
自動故障轉移（哨兵機制）
Redis中提供了Sentinel哨兵機制，由多個哨兵組成一個哨兵集群，負責保障Redis集群的高可用性，當Master節點發生故障時，自動的將其中一個Slave節點斷開與Master節點的連接並使其成為新的Master節點，並將其他的Slave節點與新的Master節點建立連接，最后修改各個節點的redis.conf配置文件，更新主從映射關系。
1.每個哨兵節點每隔10s會向Master發送info replication命令，獲取當前集群最新的拓撲結構，此時每個哨兵就能獲取到各個Slave節點的連接信息。
2.每個哨兵每隔1s會向集群中的Master和各個Slave節點發送心跳，根據心跳來判斷節點是否存活，若在一定時間內節點沒有回復，那么該哨兵認為該節點已經故障。
3.每個哨兵每隔2s會向Redis中的指定頻道發布其對Master節點的判斷，同時每個哨兵會訂閱該頻道，因此每個哨兵都能知道其他哨兵對Master節點的判斷。
4.當其中一個哨兵發現Master節點故障后，會查看其他哨兵對Master節點的判斷，若超過指定個數個哨兵都認為該節點故障，那么由該哨兵充當哨兵集群的Leader進行故障轉移，故障轉移的步驟與手動轉移的一致，挑選其中一個存活的Slave節點斷開與Master節點的連接，並使其成為新的Master節點，然后將其他Slave節點與該新的Master節點建立聯系，最后修改各個節點的redis.conf配置文件，更新主從映射關系，保證當集群重啟時以最新的主從映射關系運行，避免發生主從數據不一致的問題。
在Redis的源碼目錄中存在sentinal.conf配置文件，該文件是哨兵的配置文件。
#監聽Master節點的信息
sentinel monitor <master-name> <ip> <port> <quorum>
*其中quorum表示當哨兵集群中有quorum個哨兵都認為Master節點不可用時則哨兵集群認為該節點已經故障.
#心跳超時時間
sentinel down-after-milliseconds <master-name> <milliseconds>
#故障轉移超時時間
sentinel failover-timeout <master-name> <milliseconds>
#允許同時有多少個從節點同步新節點的數據
sentinel parallel-syncs <master-name> <numreplicas>
*一個哨兵集群可以同時監控多個Redis主從復制集群。
分別啟動各個Redis節點，然后通過redis-sentinel分別啟動各個哨兵，由於每個哨兵都關聯同一個Master，因此這多個哨兵自動成為集群關系。
*在主從復制集群中，一般都會使用自動故障轉移方案（哨兵機制）
3.Redis數據分片集群
Redis在3.0版本后推出了RedisCluster用於搭建數據分片集群。
*其中每個Master節點負責指定范圍的槽以及槽范圍內的數據，並提供讀寫服務，Slave節點只負責同步Master節點中的數據，不支持進行讀取。
*使用RedisCluster時，Master節點的個數至少需要三個，每個Master可以有任意個Slave節點。
*RedisCluster使用虛擬槽的方式進行數據分片，Redis中虛擬槽的范圍為0~16383（共16384個槽），每個Master節點負責指定范圍的槽以及槽范圍內的數據（每個槽與很多Key進行關聯，這些Key都在該Master節點的內存中）
*所有Key在進行讀取和寫入操作時，都需要根據H(K) = CRC16[K] & 16383散列函數計算出Key所坐落的槽，然后找到其對應處理的Master節點，最后自動跳轉到該節點進行操作。
由於使用了RedisCluster，數據將分散到各個節點中，因此有些操作是不允許的
1.涉及多個Key的操作，比如mset、sinter等。
2.事務不能跨節點。
3.不支持多數據庫，每個Master節點只能有一個數據庫。
4.不支持Pipeline（管道）
關於數據分片的路由策略
數據分片的路由策略一般有三種，分別是除留余數法、一致性Hash、虛擬槽，RedisCluster使用虛擬槽的方式實現數據分片。
除留余數法：以元素被某個整數M整除后所得到的余數找對其對應處理的節點（ H(K) = K % M，M等於節點的個數）
*當增加或減少節點時，數據的路由將發生變化，伸縮性很差。
一致性Hash：以元素通過某個散列函數H(K)所得到的散列值坐落在Hash環上的位置，找到其對應處理的節點。
1.首先將集群中的節點IP通過散列函數H(K)計算出散列值並使其坐落在Hash環上，每個節點負責Hash環上特定范圍的請求。
2.將元素通過相同的散列函數H(K)計算出散列值，以該散列值坐落在Hash環上的位置找對其對應的處理節點。
*使用此方式很難保證客戶端的請求平均分配到各個節點中，不能很好的實現負載均衡。
虛擬槽：以元素通過某個散列函數H(K)所得到的槽位，找到其對應處理的節點。
1.每個節點負責指定槽范圍內的請求。
2.將元素通過散列函數H(K)計算出槽位，找到其對應處理的節點。
3.1 搭建數據分片集群
可以通過手動或者自動的方式搭建數據分片集群。
手動搭建數據分片集群
1.准備配置文件
#開啟RedisCluster模式
cluster-enabled yes
#RedisCluster集群配置文件，存放集群間節點的信息。
cluster-config-file nodes-6379.conf
#節點超時時間(ms)
cluster-node-timeout 15000
2.分別啟動各個Redis節點
*當啟動Redis節點后，會生成nodes.conf文件，該文件記錄着集群間節點的關系（此時只有本節點信息）
*每個節點都有一個ClusterID，且角色默認都是Master。
3.握手（使各個節點建立關系）
*連接任意一個節點，然后分別對剩余的節點進行握手。
*當握手成功后，在node.conf文件中能看到集群間完整的節點信息。
4.分配槽
5.主從映射
*分別連接要作為Slave的節點，然后通過ClusterID與Master進行關聯。
6.使用集群的模式連接RedisCluster
*其中cluster nodes命令能夠查看集群間節點的信息，其讀取的是node.conf文件中信息，cluster info命令能夠查看集群的狀態信息。
*當槽分配完成后，此時集群將處於上線狀態，當集群中任意一個Master節點故障后，如果沒有對應的Slave節點，那么集群將處於下線狀態，當集群處於下線狀態時，不能對外提供服務。
*當集群搭建完成后，可以進行關閉以及重啟，當重啟集群時，會自動讀取node.conf文件中的信息恢復集群間的關系，並讀取dump.rdb文件進行數據的恢復。
*當需要重新構建集群關系時，需要刪除每個節點的node.conf以及rdb文件，否則集群搭建不成功。
*當使用集群的模式連接RedisCluster后，當進行讀取和寫入操作時，會通過H(K)散列函數計算出Key所在的槽，然后找到其對應處理的Master節點，最后自動跳轉到該節點進行操作。
*不管是讀取還是寫入操作，都會統一跳轉到對應處理的Master節點，slave-read-only=yes配置只適用於主從復制集群模式。
自動搭建數據分片集群
RedisCluster使用ruby來自動搭建數據分片集群。
1.環境准備
需要安裝ruby，並且安裝redis.gem
2.准備配置文件
#開啟RedisCluster模式
cluster-enabled yes
#RedisCluster集群配置文件，存放集群間節點的信息。
cluster-config-file nodes-6379.conf
#節點超時時間(ms)
cluster-node-timeout 15000
3.分別啟動各個Redis節點
4.使用redis-trib.rb命令自動完成握手、分配槽、主從映射
redis-trib.rb create --replicas <slaveNum> <ip:port..>
*其中slaveNum為每個Master節點的Slave個數，可以為0。
*只能使用ip地址，不能使用主機名。
3.2 數據分片集群中的狀態同步
RedisCluster使用基於Gossip協議的PING/PONG通訊來保證集群間狀態的同步
Gossip協議
Gossip協議主要用在分布式系統中各個節點的數據同步。
Gossip協議中提供了三種通訊類型：
1.PUSH類型：A節點將數據發送給B節點，B節點更新A節點比自己新的數據。
2.PULL類型：A節點將數據發送給B節點，B節點返回比A節點新的數據，A節點再更新自己。
3.PULL/PUSH類型：A節點將數據發送給B節點，B節點返回比A節點新的數據，A節點再更新自己，然后A節點將數據發送給B節點，B節點更新A節點比自己新的數據。
*PUSH類型目的是讓其他節點更新。
*PULL類型目的是更新自身節點的信息。
*每個消息都有一個時間戳，用來區分新老信息。
RedisCluster中的PING/PONG通訊
PING：發送集群中節點的信息、角色、集群ID、時間戳。
PONG：響應PING的請求。
*PING請求即Gossip協議中的PUSH，目的是讓其他節點進行更新。
RedisCluster中的每個節點都會定期的向其他節點發送PING請求，用於集群間狀態的同步以及檢測節點的可用性。
當集群中有新節點加入時（經過Meet操作），該節點會向其他節點發送PING請求，同時其他節點也會向其發送PING請求，最終達到數據一致性。
*RedisCluster中的節點故障是通過Master投票決定的，當有半數的Master認為該節點故障時，那么集群認為該節點故障，如果故障的節點是Master，那么會將其Slave節點切換為Master。
*當RedisCluster中有一半的Master同時失效，那么整個集群將不可用，因為已經沒有足夠的Master進行投票。
4.JAVA中使用Redis集群
4.1 使用主從復制集群
*Jedis中通過JedisSentinelPool實例來使用主從復制集群，連接主從復制集群中所有哨兵的地址，並指定哨兵配置文件中Master的名稱。
/** * @Auther: ZHUANGHAOTANG * @Date: 2019/4/2 17:11 * @Description: */
public class RedisUtils { private static final String masterName = "mymaster"; private static JedisSentinelPool jedisSentinelPool = null; static { //連接主從復制集群中所有哨兵地址
Set<String> connectionMes = new HashSet<>(); connectionMes.add("192.168.2.90:26379"); connectionMes.add("192.168.2.91:26379"); connectionMes.add("192.168.2.92:26379"); //連接池配置
JedisPoolConfig poolConfig = new JedisPoolConfig(); //最大連接數
poolConfig.setMaxTotal(10); //最大空閑連接數
poolConfig.setMaxIdle(5); jedisSentinelPool = new JedisSentinelPool(masterName, connectionMes, poolConfig); } public static Jedis getConnection() { return jedisSentinelPool.getResource(); } }
4.2 使用數據分片集群
*Jedis中通過JedisCluster實例使用數據分片集群，連接數據分片集群中所有節點（可以直接創建JedisCluster實例，也可以添加連接池進行管理）
/** * @Auther: ZHUANGHAOTANG * @Date: 2019/4/2 17:11 * @Description: */
public class RedisUtils { private static JedisCluster jedisCluster = null; static { //連接RedisCluster中的所有節點
Set<HostAndPort> connectionMes = new HashSet<>(); connectionMes.add(new HostAndPort("192.168.2.90", 6379)); connectionMes.add(new HostAndPort("192.168.2.90", 6380)); connectionMes.add(new HostAndPort("192.168.2.91", 6379)); connectionMes.add(new HostAndPort("192.168.2.91", 6380)); connectionMes.add(new HostAndPort("192.168.2.92", 6379)); connectionMes.add(new HostAndPort("192.168.2.92", 6380)); //連接池配置
JedisPoolConfig poolConfig = new JedisPoolConfig(); //最大連接數
poolConfig.setMaxTotal(10); //最大空閑連接數
poolConfig.setMaxIdle(5); jedisCluster = new JedisCluster(connectionMes, poolConfig); } }
*當使用集群的模式連接RedisCluster時，當進行讀取和寫入操作時，會隨機連接集群中的一個節點，然后根據H(K)散列函數計算出Key所坐落的槽，然后找到該槽所對應處理的Master節點，最后自動跳轉到該節點中進行操作。
5.Redis集群數據遷移方案
5.1 主從復制集群的數據遷移
當需要將當前主從復制集群中的數據遷移到一個新的主從復制集群時
1.搭建新的主從復制集群，然后關閉集群，先關閉所有Slave節點，再關閉Master節點，避免發生主從切換。
2.將舊集群中的Master節點的RDB文件復制到新集群中的Master節點。
3.重啟新集群，自動進行數據的恢復。
*先關閉新集群再進行RDB文件的遷移，是因為當節點進行shutdown操作時，會自動觸發bgsave命令，避免RDB文件被替換。
*關閉集群時先關閉所有Slave節點再關閉Master節點，是為了避免發生主從切換，當重啟集群時，導致主從數據不一致的問題。
5.2 數據分片集群的數據遷移
當需要將當前數據分片集群中的數據遷移到一個新的數據分片集群時
1.使用與舊集群相同的Master節點個數以及相同的槽范圍搭建新的數據分片集群（手動/自動搭建）
2.依次關閉新集群中的各個節點，先關閉所有Slave節點，再關閉所有Master節點，避免發生主從切換以及RDB文件被替換。
3.根據舊集群的node.conf文件查看Master節點的相關信息，再查看新集群的node.conf文件中Master節點的相關信息，然后將舊集群中的Master節點的RDB文件復制到新集群對應槽范圍的Master節點中，最后重啟新集群，自動進行數據恢復。
*根據兩個集群的node.conf文件來確定相同槽范圍的Master節點的映射關系。
*不管是主從復制集群還是數據分片集群，新集群中的Slave節點的個數都不需要和舊集群的一致。
6.Redis集群擴容
Redis集群擴容是相對於數據分片集群來說的，在現有集群的架構下，通過增加多個Master節點來提高Redis集群的負載能力。
6.1 准備要加入到集群的節點
*根據實際的業務情況決定要增加的Master節點個數，以及對應Slave節點的個數。
6.2 分別進行握手，使其加入到集群中
6.3 進行槽位和數據的遷移
*使用redis-trib.rb reshared --timeout <timeout> <ip>:<port>命令進行槽位和數據的遷移，其中timeout指定每個槽遷移時最大的超時時間，ip和端口指定接收槽和數據的目標節點。
*需要指定在當前集群中移動多少個槽位到目標節點中，值可以選1~16384，並且需要指定目標節點在集群中的ID。
*可以選擇all和done兩種遷移模式，其中all表示將集群中的所有節點作為槽的源節點（平均分配），done表示指定集群中的某個節點作為槽的源節點。
*在槽和數據遷移的過程中，用戶的請求會有相應的延時，整個遷移過程所需要的時間與Redis集群中的數據量成正比（線上試過平均2.5s遷移一個槽，遷移6000個槽耗費了4小時）
*在槽和數據遷移的過程中，如果某個槽位在遷移時報錯，那么Redis會停止遷移，在它之前遷移的槽和數據仍會生效，當再次遷移時需要執行fix命令（會有提示），刪除遷移失敗的槽位的數據。
*使用了all模式，可見遷移后的槽從之前的Master中分別平均抽取1364/1365個槽。
6.4 主從映射
