Redis哨兵（Sentinel）模式的配置方法及其在Java中的用法

主從切換技術的方法是：當主服務器宕機后，需要手動把一台從服務器切換為主從服務器，這就需要人工干預，既費時費力，還會造成一段時間內服務不可用，這不是一種推薦的方式，因此筆者沒有介紹主從切換技術。

更多的時候，我們優先考慮哨兵模式，它是當前企業應用的主流方式。

哨兵模式概述

Redis 可以存在多台服務器，並且實現了主從復制的功能。哨兵模式是一種特殊的模式，首先 Redis 提供了哨兵的命令，哨兵是一個獨立的進程，作為進程，它會獨立運行。

其原理是哨兵通過發送命令，等待 Redis 服務器響應，從而監控運行的多個 Redis 實例，如圖 1 所示。

圖 1  Redis哨兵

這里的哨兵有兩個作用：

• 通過發送命令，讓 Redis 服務器返回監測其運行狀態，包括主服務器和從服務器。
• 當哨兵監測到 master 宕機，會自動將 slave 切換成 master，然后通過發布訂閱模式通知到其他的從服務器，修改配置文件，讓它們切換主機。

只是現實中一個哨兵進程對 Redis 服務器進行監控，也可能出現問題，為了處理這個問題，還可以使用多個哨兵的監控，而各個哨兵之間還會相互監控，這樣就變為了多個哨兵模式。多個哨兵不僅監控各個 Redis 服務器，而且哨兵之間互相監控，看看哨兵們是否還“活”着，其關系如圖 2 所示。

論述一下故障切換（failover）的過程。假設主服務器宕機，哨兵 1 先監測到這個結果，當時系統並不會馬上進行 failover 操作，而僅僅是哨兵 1 主觀地認為主機已經不可用，這個現象被稱為主觀下線。

當后面的哨兵監測也監測到了主服務器不可用，並且有了一定數量的哨兵認為主服務器不可用，那么哨兵之間就會形成一次投票，投票的結果由一個哨兵發起，進行 failover 操作，在 failover 操作的過程中切換成功后，就會通過發布訂閱方式，讓各個哨兵把自己監控的服務器實現切換主機，這個過程被稱為客觀下線。這樣對於客戶端而言，一切都是透明的。

圖 2  多哨兵監控Redis

搭建哨兵模式

配置 3 個哨兵和 1 主 2 從的 Redis 服務器來演示這個過程。機器的分配，如表 1 所示：

表 1 機器分配

服務類型	是否主服務器	IP地址	端口
Redis	是	192.168.11.128	6379
Redis	否	192.168.11.129	6379
Redis	否	192.168.11.130	6379
Sentinel	——	192.168.11.128	26379
Sentinel	——	192.168.11.129	26379
Sentinel	——	192.168.11.130	26379

它的結構就如同圖 2 所示，下面對它們進行配置。首先配置 Redis 的主從服務器，修改服務器的 redis.conf 文件，下面的配置內容，僅僅是筆者在原有文件的基礎上修改的內容：

#使得Redis服務器可以跨網絡訪問
bind 0.0.0.0
#設置密碼
requiredpass "abcdefg"
#指定主服務器，注意：有關slaveof的配置只是配置從服務器，而主服務器不需要配置
slaveof 192.168.11.128 6379
#主服務器密碼，注意：有關slaveof的配置只是配置從服務器，而主服務器不需要配置
masterauth abcdefg

上述內容主要是配置 Redis 服務器，從服務器比主服務器多一個 slaveof 的配置和密碼，這里配置的 bind 使得 Redis 服務器可以跨網段訪問。而對於外部的訪問還需要提供密碼，因此還提供了 requirepass 的配置，用以配置密碼，這樣就配置完了 3 台服務器。

配置 3 個哨兵，每一個哨兵的配置都是一樣的，在 Redis 安裝目錄下可以找到 sentinel.conf 文件，然后對其進行修改。

下面對 3 個哨兵的這個文件作出修改，同樣也是在原有的基礎上進行修改，如下所示。

#禁止保護模式
protected-mode no
#配置監聽的主服務器，這里 sentinel monitor 代表監控
#mymaster代表服務器名稱，可以自定義
#192.168.11.128代表監控的主服務器
#6379代表端口
#2代表只有兩個或者兩個以上的燒餅認為主服務器不可用的時候，才會做故障切換操作
sentinel monitor mymaster 192.168.11.128 6379 2
#sentinel auth-pass 定義服務的密碼
#mymaster服務名稱
#abcdefg Redis服務器密碼
sentinel auth-pass mymaster abcdefg

上述關閉了保護模式，以便測試。sentinel monitor 是配置一個哨兵主要的內容，首先是自定義服務名稱 mymaster，然后映射服務器和端口。最后的 2 是代表當存在兩個或者兩個以上的哨兵投票認可當前主服務器不可用后，才會進行故障切換，這樣可以降低因出錯而切換主服務器的概率。sentinel auth-pass 用於配置服務名稱及其密碼。

有了上述的修改，我們可以進入 Redis 的安裝目錄下的 src 目錄，通過以下命令啟動 Redis 服務器和哨兵，如下所示：

#啟動哨兵進程
./redis-sentinel ../sentinel.conf
#啟動Redis服務器進程
./redis-server ../redis.conf

只是這里要注意服務器啟動的順序，首先是主機（192.168.11.128）的 Redis 服務進程，然后啟動從機的服務進程，最后啟動 3 個哨兵的服務進程。這里可以從哨兵啟動的輸出窗口看一下哨兵監控信息，如圖 3 所示。

從圖 3 中，我們看到了一個哨兵對多台 Redis 服務器進行了監控。

在 Java 中使用哨兵模式

在 Java 中使用哨兵模式，加入關於哨兵的信息即可，非常簡單，下面代碼展示了這樣的一個過程。

1. //連接池配置
2. JedisPoolConfig jedisPoolConfig = new JedisPoolConfig();
3. jedisPoolConfig.setMaxTotal(10);
4. jedisPoolConfig.setMaxIdle(5);
5. jedisPoolConfig.setMinIdle(5);
6. //哨兵信息
7. Set<String> sentinels = new HashSet<String>(Arrays.asList(
8. "192.168.11.128:26379",
9. "192.168.11.129:26379",
10. "192.168.11.130:26379"
11. ));
12. //創建連接池
13. //mymaster是我們配置給哨兵的服務名稱
14. //sentinels是哨兵信息
15. //jedisPoolConfig是連接池配置
16. //abcdefg是連接Redis服務器的密碼
17. JedisSentinelPool pool = new JedisSentinelPool("mymaster", sentinels, jedisPoolConfig, "abcdefg");
18. //獲取客戶端
19. Jedis jedis = pool.getResource();
20. //執行兩個命令
21. jedis.set("mykey", "myvalue");
22. String myvalue = jedis.get("mykey");
23. //打印信息
24. System.out.println(myvalue);

圖 3  哨兵監控信息

通過上述的代碼就能夠連接 Redis 服務器了，這個時候將啟動主機（192.168.11.128）提供服務。為了驗證哨兵的作用，我們可以把主機上的 Redis 服務器關閉，馬上運行，你就可以發現報錯，那倒不是因為哨兵失效導致的，而是因為 Redis 哨兵默認超時 3 分鍾后才會進行投票切換主機，等超過 3 分鍾后再進行測試。

同樣的，通過配置也可以實現在 Spring 中使用哨兵的這些功能，代碼如下所示。

1. <?xml version="1.0" encoding="UTF-8"?>
2. <beans xmlns="http://www.springframework.org/schema/beans"
3. xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
4. xmlns:p="http://www.springframework.org/schema/p"
5. xsi:schemaLocation="http://www.springframework.org/schema/beans
6. http://www.springframework.org/schema/beans/spring-beans-3.2.xsd">
7. <bean id="poolConfig" class="redis.clients.jedis.JedisPoolConfig">
8. <!-- 最大空閑數 -->
9. <property name="maxIdle" value="50" />
10. <!-- 最大連接數 -->
11. <property name="maxTotal" value="100" />
12. <!-- 最大等待時間 -->
13. <property name="maxWaitMillis" value="30000" />
14. </bean>
15. <!-- jdk序列化器，可保存對象 -->
16. <bean id="jdkSerializationRedisSerializer"
17. class="org.springframework.data.redis.serializer.JdkSerializationRedisSerializer" />
18. <!-- String序列化器 -->
19. <bean id="stringRedisSerializer"
20. class="org.springframework.data.redis.serializer.StringRedisSerializer" />
22. <!-- 哨兵配置 -->
23. <bean id="sentinelConfig"
24. class="org.springframework.data.redis.connection.RedisSentinelConfiguration">
25. <!-- 服務名稱 -->
26. <property name="master">
27. <bean class="org.springframework.data.redis.connection.RedisNode">
28. <property name="name" value="mymaster" />
29. </bean>
30. </property>
31. <!-- 哨兵服務IP和端口 -->
32. <property name="sentinels">
33. <set>
34. <bean class="org.springframework.data.redis.connection.RedisNode">
35. <constructor-arg name="host" value="192.168.11.128" />
36. <constructor-arg name="port" value="26379" />
37. </bean>
38. <bean class="org.springframework.data.redis.connection.RedisNode">
39. <constructor-arg name="host" value="192.168.11.129" />
40. <constructor-arg name="port" value="26379" />
41. </bean>
42. <bean class="org.springframework.data.redis.connection.RedisNode">
43. <constructor-arg name="host" value="192.168.11.130" />
44. <constructor-arg name="port" value="26379" />
45. </bean>
46. </set>
47. </property>
48. </bean>
49. <!-- 連接池設置 -->
50. <bean id="connectionFectory"
51. class="org.springframework.data.redis.connection.jedis.JedisConnectionFactory">
52. <constructor-arg name="sentinelConfig" ref="sentinelConfig" />
53. <constructor-arg name="poolConfig" ref="poolConfig" />
54. <property name="password" value="abcdefg" />
55. </bean>
56. <!-- 配置 RedisTemplate -->
57. <bean id="redisTemplate" class="org.springframework.data.redis.core.RedisTemplate">
58. <property name="connectionFactory" ref="connectionFactory" />
59. <property name="keySerializer" ref="stringRedisSerializer" />
60. <property name="defaultSerializer" ref="stringRedisSerializer" />
61. <property name="valueSerializer" ref="jdkSerializationRedisSerializer" />
62. </bean>
63. </beans>

這樣就在 Spring 中配置好了哨兵和其他的內容，使用 Spring 測試哨兵，代碼如下所示。

1. public static void testLuaFile() {
2. ApplicationContext applicationContext = new ClassPathXmlApplicationContext("applicationContext.xml");
3. RedisTemplate redisTemplate = applicationContext.getBean(RedisTemplate.class);
4. String retVal = (String)redisTemplate.execute((RedisOperations ops)->{
5. ops.boundValueOps("mykey").set("myvalue");
6. String value = (String)ops.boundValuesOps("mykey").get();
7. return value;
8. });
9. System.out.println(retVal);
10. }

這樣在實際的項目中，就可以使用哨兵模式來提高系統的可用性和穩定了。

哨兵模式的其他配置項

上述以最簡單的配置完成了哨兵模式。哨兵模式的配置項還是比較有用的，比如上述我們需要等待 3 分鍾后，Redis 哨兵進程才會做故障切換，有時候我們希望這個時間短一些，下面再對它們進行一些介紹，如表 2 所示。

表 2 哨兵模式的其他配置項

配置項	參數類型	作用
port	整數	啟動哨兵進程端口
dir	文件夾目錄	哨兵進程服務臨時文件夾，默認為 /tmp，要保證有可寫入的權限
sentinel down-after-milliseconds	<服務名稱><亳秒數（整數）>	指定哨兵在監測 Redis 服務時，當 Redis 服務在一個亳秒數內都無 法回答時，單個哨兵認為的主觀下線時間，默認為 30000（30秒）
sentinel parallel-syncs	<服務名稱><服務器數（整數）>	指定可以有多少 Redis 服務同步新的主機，一般而言，這個數字越 小同步時間就越長，而越大，則對網絡資源要求則越高
sentinel failover-timeout	<服務名稱><亳秒數（整數）>	指定在故障切換允許的亳秒數，當超過這個亳秒數的時候，就認為 切換故障失敗，默認為 3 分鍾
sentinel notification-script	<服務名稱><腳本路徑>	指定 sentinel 檢測到該監控的 redis 實例指向的實例異常時，調用的 報警腳本。該配置項可選，比較常用

sentinel down-after-milliseconds 配置項只是一個哨兵在超過其指定的毫秒數依舊沒有得到回答消息后，會自己認為主機不可用。對於其他哨兵而言，並不會認為主機不可用。

哨兵會記錄這個消息，當擁有認為主觀下線的哨兵到達 sentinel monitor 所配置的數量的時候，就會發起一次新的投票，然后切換主機，此時哨兵會重寫 Redis 的哨兵配置文件，以適應新場景的需要。