Redis高可用集群-哨兵模式（Redis-Sentinel）搭建配置教程【Windows环境】

大家好，又见面了，我是全栈君。

=================================================

人工智能教程。零基础！通俗易懂！风趣幽默！大家可以看看是否对自己有帮助！
点击查看高清无码教程

=================================================

No cross,no crown . 不经历风雨，怎么见彩虹。

Redis哨兵模式，用现在流行的话可以说就是一个“哨兵机器人”，给“哨兵机器人”进行相应的配置之后，这个”机器人”可以7*24小时工作，它能能够自动帮助你做一些事情，如监控，提醒，自动处理故障等。

Redis-sentinel简介

Redis-sentinel是Redis的作者antirez，因为Redis集群的被各大公司使用，每个公司要写自己的集群管理工具，于是antirez花了几个星期写出了Redis-sentinel。

Redis 的 Sentinel 系统用于管理多个 Redis 服务器（instance），Redis 的 Sentinel 为Redis提供了高可用性。使用哨兵模式创建一个可以不用人为干预而应对各种故障的Redis部署。

该系统执行以下三个任务：

• 监控（Monitoring）：Sentinel会不断地检查你的主服务器和从服务器是否允许正常。
• 提醒（Notification）：当被监控的某个Redis服务器出现问题时，Sentinel可以通过API向管理员或者其他应用程序发送通知。
• 自动故障迁移（Automatic failover）: （1）当一个主服务器不能正常工作时，Sentinel会开始一次自动故障迁移操作，他会将失效主服务器的其中一个从服务器升级为新的主服务器，并让失效主服务器的其他从服务器改为复制新的主服务器；
  （2）客户端试图连接失败的主服务器时，集群也会向客服端返回新主服务器的地址，是的集群可以使用新主服务器代替失效服务器。

sentinel的分布式特性

Redis Sentinel 是一个分布式系统， 你可以在一个架构中运行多个 Sentinel 进程（progress）， 这些进程使用流言协议（gossip protocols)来接收关于主服务器是否下线的信息， 并使用投票协议（agreement protocols）来决定是否执行自动故障迁移， 以及选择哪个从服务器作为新的主服务器。

单个sentinel进程来监控redis集群是不可靠的，当sentinel进程宕掉后(sentinel本身也有单点问题，single-point-of-failure)整个集群系统将无法按照预期的方式运行。所以有必要将sentinel集群，这样有几个好处：

• 有一些sentinel进程宕掉了，依然可以进行redis集群的主备切换；

• 如果只有一个sentinel进程，如果这个进程运行出错，或者是网络堵塞，那么将无法实现redis集群的主备切换（单点问题）;

• 如果有多个sentinel，redis的客户端可以随意地连接任意一个sentinel来获得关于redis集群中的信息

一个健壮的部署至少需要三个哨兵实例。

三个哨兵实例应该放置在客户使用独立方式确认故障的计算机或虚拟机中。例如不同的物理机或不同可用区域的虚拟机。【本次讲解是一个机器上进行搭建，和多级是一个道理】

Redis-sentinel搭建

1. 环境

Windows10
Redis-x64-3.2.100


本次搭建说明：
master：127.0.0.1:6379 【初始化master】

slave：127.0.0.1:6380  127.0.0.1:6381

sentinel：127.0.0.1:26379  127.0.0.1:26380  127.0.0.1:26381

2. 安装和基本配置

因为之前已经介绍过Redis集群的主从配置，里面有安装和基本配置，所以这里不做介绍，不懂的请查看：Redis集群主从复制（一主两从）搭建配置教程【Windows环境】

3. Sentinel配置
   根据安装和基本配置，已经有了主从配置 ，对应文件夹Redis6379~Redis6381。然后在每个文件夹下面新增 一个名为 sentinel.conf 的文件。配置内容如下：

# 这个是Redis6379配置内容，其他文件同理新增然后改一下端口即可，26380，和 26381。

#当前Sentinel服务运行的端口
port 26379  
# 哨兵监听的主服务器 
sentinel monitor mymaster 127.0.0.1 6379 2
# 3s内mymaster无响应，则认为mymaster宕机了
sentinel down-after-milliseconds mymaster 3000
#如果10秒后,mysater仍没启动过来，则启动failover  
sentinel failover-timeout mymaster 10000  
# 执行故障转移时， 最多有1个从服务器同时对新的主服务器进行同步
sentinel parallel-syncs mymaster 1

配置文件只需要配置master的信息就好啦，不用配置slave的信息，因为slave能够被自动检测到(master节点中有关于slave的消息)。

为了更清楚每一行配置的含义，对每个选项的含义进行简单介绍：

sentinel monitor [master-group-name] [ip] [port] [quorum]

• master-group-name：master名称（可以自定义）
• ip port : IP地址和端口号
• quorun：票数，Sentinel需要协商同意master是否可到达的数量。

第一行配置指示 Sentinel 去监视一个名为 mymaster 的主服务器， 这个主服务器的 IP 地址为 127.0.0.1 ， 端口号为 6379 ， 而将这个主服务器判断为失效至少需要 2 个 Sentinel 同意 （只要同意 Sentinel 的数量不达标，自动故障迁移就不会执行）。
票数在本文中：redis集群中有3个sentinel实例，其中master挂掉啦，这里设置票数为2，表示有2个sentinel认为master挂掉啦，才能被认为是正真的挂掉啦。

sentinel <选项的名字> <主服务器的名字> <选项的值>

• down-after-milliseconds 选项指定了 Sentinel 认为服务器已经断线所需的毫秒数。

如果服务器在给定的毫秒数之内， 没有返回 Sentinel 发送的 PING 命令的回复， 或者返回一个错误， 那么 Sentinel 将这个服务器标记为主观下线（subjectively down，简称 SDOWN ）。
不过只有一个 Sentinel 将服务器标记为主观下线并不一定会引起服务器的自动故障迁移： 只有在足够数量的 Sentinel 都将一个服务器标记为主观下线之后， 服务器才会被标记为客观下线（objectively down， 简称 ODOWN ）， 这时自动故障迁移才会执行。
将服务器标记为客观下线所需的 Sentinel 数量由对主服务器的配置决定。

• parallel-syncs 选项指定了在执行故障转移时， 最多可以有多少个从服务器同时对新的主服务器进行同步， 这个数字越小， 完成故障转移所需的时间就越长。

5.其他配置
新增Redis启动脚本：startRedisServer.bat

@echo off
redis-server.exe redis.windows.conf
@pause

新增Redis-Sentinel启动脚本：startRedisSentinel.bat

@echo off
redis-server.exe sentinel.conf --sentinel 
@pause

在配置启动startrRedis6379.cmd,其他同理！

@echo off
cd Redis6379
startRedisServer.bat

在配置启动startrRedisSentinel26379.cmd，其他同理！

@echo off
cd Redis6379
startRedisSentinel.bat
at

配置完如图：

6. 启动Sentinel实例

哨兵启动命令 redis-server.exe sentinel.conf –sentinel

第一步：点击startRedis.cmd ，启动Redis集群

第二步：点击startRedisSentinel.cmd ，启动哨兵实例

查看Sentinel启动日志，看到“`
生成哨兵ID（Sentinel ID），并自动识别主服务器和从服务器！

[114252] 03 Mar 13:32:57.896 # Sentinel ID is 89f521b40a803495472c0457b0396473c4bfb100
[114252] 03 Mar 13:32:57.896 # +monitor master mymaster 127.0.0.1 6379 quorum 2
[114252] 03 Mar 13:32:57.909 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
[114252] 03 Mar 13:32:57.917 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379

查看主服务器6379（Master）信息：

F:\nosql_learn\Redis-Sentinel\Redis6379>redis-cli -p 6379
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6380,state=online,offset=54148,lag=1
slave1:ip=127.0.0.1,port=6381,state=online,offset=54148,lag=1
master_repl_offset:54414
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:54413
127.0.0.1:6379>

查看主服务器6380（Slave）信息：

127.0.0.1:6380> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:0
master_sync_in_progress:0
slave_repl_offset:80531
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
127.0.0.1:6380>

Redis-Sentinel高可用场景演示

场景1：主服务器master宕机

当主服务器master宕机，那么Sentinel会通过选举（算法）机制，从Salve中选出一个作为新Master。
大概原理是当选出一个Slave要作为Master的时候，会发送命令slaveofno one来取消选中的这个slave，使其成为Master。哨兵会发送给其他从服务器Slave配置选中的这个为新主服务器Master，并删除监听列表中出现故障的Master服务器。
(1)关闭掉 6379主服务器

127.0.0.1:6379> shutdown
not connected>

(2)查看观察选举新的master的过程和显示了failover的过程，整个日志信息还是比较完整的。最后选举了6381为主服务器！

[114252] 03 Mar 13:32:59.945 * +sentinel sentinel 926e67646440b200ee41bb224bacf9e0314e3b32 127.0.0.1 26379 @ mymaster 127.0.0.1 6379
[114252] 03 Mar 13:33:00.018 * +sentinel sentinel 7fc21e38de0408ccaa06111e44638e2693794e08 127.0.0.1 26380 @ mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:19.223 # +sdown master mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:19.300 # +odown master mymaster 127.0.0.1 6379 #quorum 2/2
[114252] 03 Mar 13:53:19.300 # +new-epoch 1
[114252] 03 Mar 13:53:19.300 # +try-failover master mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:19.306 # +vote-for-leader 89f521b40a803495472c0457b0396473c4bfb100 1
[114252] 03 Mar 13:53:19.319 # 7fc21e38de0408ccaa06111e44638e2693794e08 voted for 89f521b40a803495472c0457b0396473c4bfb100 1
[114252] 03 Mar 13:53:19.369 # +elected-leader master mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:19.370 # +failover-state-select-slave master mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:19.428 # +selected-slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:19.428 * +failover-state-send-slaveof-noone slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:19.530 * +failover-state-wait-promotion slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:20.327 # +promoted-slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:20.328 # +failover-state-reconf-slaves master mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:20.398 * +slave-reconf-sent slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:21.390 * +slave-reconf-inprog slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:21.390 * +slave-reconf-done slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:21.445 # +failover-end master mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:21.445 # +switch-master mymaster 127.0.0.1 6379 127.0.0.1 6381
[114252] 03 Mar 13:53:21.447 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6381
[114252] 03 Mar 13:53:21.449 * +slave slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6381
[114252] 03 Mar 13:53:23.193 # +sdown sentinel 926e67646440b200ee41bb224bacf9e0314e3b32 127.0.0.1 26379 @ mymaster 127.0.0.1 6381
[114252] 03 Mar 13:53:24.451 # +sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6381

(3)查看6381服务器信息,角色为主，从服务器6380！

127.0.0.1:6381> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6380,state=online,offset=33358,lag=1
master_repl_offset:33505
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:33504
127.0.0.1:6381>

场景2：之前故障的6379 master重新启动

（1）启动6379服务，发现6379成为6381的从服务器！

F:\nosql_learn\Redis-Sentinel\Redis6379>redis-server.exe redis.windows.conf

[116640] 03 Mar 13:59:25.753 * The server is now ready to accept connections on port 6379
[116640] 03 Mar 13:59:48.315 * SLAVE OF 127.0.0.1:6381 enabled (user request from 'id=2 addr=127.0.0.1:61677 fd=7 name=sentinel-7fc21e38-cmd age=10 idle=0 flags=x db=0 sub=0 psub=0 multi=3 qbuf=0 qbuf-free=32768 obl=36 oll=0 omem=0 events=r cmd=exec')
[116640] 03 Mar 13:59:48.326 # CONFIG REWRITE executed with success.
[116640] 03 Mar 13:59:48.826 * Connecting to MASTER 127.0.0.1:6381
[116640] 03 Mar 13:59:48.851 * MASTER <-> SLAVE sync started

（2）查看6381服务器状态信息：原来的master自动切换成slave，不会自动恢复成master。

127.0.0.1:6381> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6380,state=online,offset=73183,lag=0
slave1:ip=127.0.0.1,port=6379,state=online,offset=73183,lag=0
master_repl_offset:73183
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:73182
127.0.0.1:6381>

场景3：从服务器Slave宕机和重启

（1）关闭6380从服务器：

127.0.0.1:6380> shutdown
not connected>

（2）Sentinel日志：

[113488] 03 Mar 14:06:50.143 # +sdown slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6381

（3）查看住服务器6381状态信息：

127.0.0.1:6381> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6379,state=online,offset=111361,lag=1
master_repl_offset:111361
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:111360
127.0.0.1:6381>

（4）启动从服务器6380

Connecting to MASTER 127.0.0.1:6381

（5）查看住服务器6381状态信息：6380又回来了！

role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6379,state=online,offset=141232,lag=0
slave1:ip=127.0.0.1,port=6380,state=online,offset=141232,lag=1
master_repl_offset:141232
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:141231
127.0.0.1:6381>

Redis-sentinel相关知识

1. 主观下线和客观下线
2. 每个 Sentinel 都需要定期执行的任务
3. 自动发现 Sentinel 和从服务器
   …

可以参考 Redis 的 Sentinel 文档

Jedis客户端使用Sentinel

;

import java.util.HashSet;
import java.util.Set;

import redis.clients.jedis.Jedis;
import redis.clients.jedis.JedisPoolConfig;
import redis.clients.jedis.JedisSentinelPool;

public class RedisManagerUtil {

	private static JedisSentinelPool pool = null;
	// 自带的哨兵模式 JedisSentinelPool, 并在一开始初始化连接池
	static {
		try {
			JedisPoolConfig config = new JedisPoolConfig();
			// 控制一个pool可分配多少个jedis实例，通过pool.getResource()来获取；
			// 如果赋值为-1，则表示不限制；如果pool已经分配了maxActive个jedis实例，则此时pool的状态为exhausted(耗尽)。
			config.setMaxTotal(Integer.valueOf(1000));
			// 控制一个pool最多有多少个状态为idle(空闲的)的jedis实例。
			config.setMaxIdle(Integer.valueOf(20));
			// 表示当borrow(引入)一个jedis实例时，最大的等待时间，如果超过等待时间，则直接抛出JedisConnectionException；
			config.setMinEvictableIdleTimeMillis(Integer.valueOf(-1));
			// 在borrow一个jedis实例时，是否提前进行validate操作；如果为true，则得到的jedis实例均是可用的；
			config.setTestOnBorrow(Boolean.valueOf(true));

			// master名称和配置文件中配置的要一样
			String master = "mymaster";
			//setinel客户端提供了master自动发现功能
			Set<String> sentinels = new HashSet<String>();
			sentinels.add("127.0.0.1:26379");
			sentinels.add("127.0.0.1:26380");
			sentinels.add("127.0.0.1:26381");

			pool = new JedisSentinelPool(master, sentinels, config);
		} catch (Exception e) {
			e.printStackTrace();
		}
	}

	/**
	 * 构建redis连接池
	 * 
	 * @return JedisPool
	 */
	public static JedisSentinelPool getPool() {
		return pool;
	}

	/**
	 * 返还到连接池
	 * 
	 * @param pool
	 * @param redis
	 */
	public static void returnResource(JedisSentinelPool pool, Jedis redis) {
		if (redis != null) {
			try {
				pool.returnResource(redis);
			} catch (Exception e) {
				e.printStackTrace();
			}
		}
	}

	/**
	 * 测试redis线程池是否正常
	 * @param args
	 */
	public static void main(String[] args) {
		JedisSentinelPool pool = RedisPoolAPIManager.getPool();
		Jedis redis = pool.getResource();
		System.out.println("redis = " + redis);

		if(redis != null){
			returnResource(pool,redis);
		}
	}
}

总结

Redis-Sentinel是Redis官方推荐的高可用性(HA) 解决方案，Redis-sentinel本身也是一个独立运行的进程，它能监控多个master-slave集群，发现master宕机后能进行自动切换。Sentinel可以监视任意多个主服务器（复用），以及主服务器属下的从服务器，并在被监视的主服务器下线时，自动执行故障转移操作。

为了防止sentinel的单点故障，可以对sentinel进行集群化，创建多个sentinel。

如果你想使用本篇博文中配置的redis-Sentinel,可以在这里Redis-Sentinel下载！

参考博文

Redis学习笔记(四) Redis哨兵(sentinel)

基于Sentinel（哨兵）搭建实现Redis高可用集群

本系列文章：

第一篇：Redis集群主从复制（一主两从）搭建配置教程【Windows环境】

第二篇：Redis高可用集群-哨兵模式搭建配置教程【Windows环境】

第三篇：Redis集群模式-主从复制搭建配置教程【Windows环境】

如果您觉得这篇博文对你有帮助，请点赞或者喜欢，让更多的人看到，谢谢！

如果帅气（美丽）、睿智（聪颖），和我一样简单善良的你看到本篇博文中存在问题，请指出，我虚心接受你让我成长的批评，谢谢阅读！
祝你今天开心愉快！

欢迎访问我的csdn博客和关注的个人微信公众号！

愿你我在人生的路上能都变成最好的自己，能够成为一个独挡一面的人。

不管做什么，只要坚持下去就会看到不一样！在路上，不卑不亢!

博客首页 : http://blog.csdn.net/u010648555

© 每天都在变得更好的阿飞