redis高可用需要保證，在主節點崩潰的時候，從節點能夠成為主節點，繼續提供服務。預設來說主從模式master-slave就能做到這一點，但是在實際環境中，用戶端連接配接的是指定的主機和端口，一旦master奔潰，那麼這個節點就無法連接配接了，需要人為設定連接配接資訊為從節點的主機和端口。redis高可用解決方案sentinel模式解決了需要手動設定從節點主機和端口的問題，sentinel模式簡稱哨兵模式，當主節點奔潰的時候，哨兵節點會通過選舉的方式選舉出一個從節點來作為主節點繼續提供redis服務。可以說sentinel哨兵模式就是在主從模式的基礎上，增加了哨兵角色，來監控系統的狀态，系統異常出現的時候，這些哨兵角色他們就發揮作用了。
搭建sentinel模式環境，需要先搭建一個主從模式，搭建一個最小的sentinel模式，需要一個master,一個slave節點，三個sentinel哨兵節點。結構圖如下所示：
搭建過程需要先啟動主從節點，然後啟動sentinel節點。這裡以一台虛拟機為例，我們啟動五個程序來搭建redis sentinel模式，安裝過redis-4.0.2之後，安裝目錄下回自動生成redis.conf sentinel.conf，我們可以拷貝複制這兩個配置檔案到/data/redis/conf目錄下，然後組成我們這個系統的配置檔案。
我們對預設的配置檔案稍作修改，設定對應的端口号，指定對應的dir和logfile、pidfile
redis.conf
bind 0.0.0.0
protected-mode yes
port 6379
daemonize yes
pidfile "/var/run/redis_6379.pid"
logfile "/data/redis/logs/redis_6379.log"
dir "/data/redis/data/6379"
slave.conf
bind 0.0.0.0
protected-mode yes
port 6380
daemonize yes
pidfile "/var/run/redis_6380.pid"
logfile "/data/redis/logs/redis_6380.log"
dir "/data/redis/data/6380"
sentinel-26379.conf
port 26379
daemonize yes
protected-mode no
dir "/data/redis/data/26379"
logfile "/data/redis/logs/redis_26379.log"
sentinel monitor mymaster 10.119.9.149 6379 2
sentinel-26380.conf
port 26380
daemonize yes
protected-mode no
dir "/data/redis/data/26380"
logfile "/data/redis/logs/redis_26380.log"
sentinel monitor mymaster 10.119.9.149 6379 2
sentinel-26381.conf
port 26381
daemonize yes
protected-mode no
dir "/data/redis/data/26381"
logfile "/data/redis/logs/redis_26381.log"
sentinel monitor mymaster 10.119.9.149 6379 2
下面可以啟動主從節點，并通過指令的方式建構一個master-slave模式。
主從複制建構完成，我們驗證主從複制：先在主節點上儲存資料，然後在從節點上檢視資料。
從節點檢視資料：
主從複制環境搭建完成，我們隻需要啟動哨兵節點即可。
故障測試,人為停止6379端口的程序，然後看看主節點是否轉移。
故障前：
停止6379程序：
故障轉移之後：
從這裡可以看出，主節點發生了改變，當6379端口服務停止之後，6380端口轉為了master，繼續提供redis連接配接服務。
sentinel哨兵模式這種高可用也是redis官方推薦的，下面通過java來調用jedis提供的api來操作sentinel叢集。下面是一個簡單的代碼：
package com.xxx.service;
import java.util.HashSet;
import java.util.Set;
import redis.clients.jedis.Jedis;
import redis.clients.jedis.JedisSentinelPool;
public class JedisSentinels {
public static JedisSentinelPool jedisSentinelPool;
private static final String master="mymaster";
private static Set<String> sentinels = new HashSet<>();
static {
sentinels.add("10.119.9.149:26379");
sentinels.add("10.119.9.149:26380");
sentinels.add("10.119.9.149:26381");
jedisSentinelPool = new JedisSentinelPool(master, sentinels);
}
public static void set(String key,String value) {
Jedis jedis = jedisSentinelPool.getResource();
try {
jedis.set(key.getBytes(), value.getBytes());
} finally {
jedis.close();
}
}
public static byte[] get(String key) {
Jedis jedis = jedisSentinelPool.getResource();
byte[] bs;
try {
bs = jedis.get(key.getBytes());
} finally {
jedis.close();
}
return bs;
}
public static void main(String[] args) {
String value = new String(get("name"));
System.out.println(value);
//set("name", "sentinel");
}
}
這個執行個體中，我們通過列印redis中key為name的value。運作列印結果如下：
代碼中，我們使用的是JedisSentinelPool來建構redis連接配接池，他需要傳入一個masterName和sentinels集合作為參數，sentinels集合就是我們搭建環境中的sentinel角色的主機和端口集合，是以當系統出現故障的時候，我們無需手動修改代碼，當sentinel哨兵角色選舉出新的主節點之後，該系統仍然可以繼續服務。調用者對于系統故障無感覺。 這就是為什麼redis官方也推薦這種叢集方式的原因。