sentinel 美[ˈsɛntənəl]

n.岗哨，哨兵;

Redis-Sentinel是Redis官方推荐的高可用性(HA)解决方案，当用Redis做Master-slave的高可用方案时，假如master宕机了，Redis本身(包括它的很多客户端)都没有实现自动进行主备切换，而Redis-sentinel本身也是一个独立运行的进程，它能监控多个master-slave集群，发现master宕机后能进行自动切换。

Sentinel也支持集群

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

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

如果只有一个sentinel进程，如果这个进程运行出错，或者是网络堵塞，那么将无法实现redis集群的主备切换（单点问题）;如果有多个sentinel，redis的客户端可以随意地连接任意一个sentinel来获得关于redis集群中的信息。

sentinel默认监听26379端口，所以运行前必须确定该端口没有被别的进程占用。

使用Jedis链接sentinel集群示例代码：

public class Test {
	
	private static Pool<Jedis> pool;
	static{
		JedisPoolConfig config = new JedisPoolConfig();
		//最大连接数
		config.setMaxTotal(800);
		//最大空闲连接数
		config.setMaxIdle(10);
		//连接耗尽时是否阻塞, false报异常,ture阻塞直到超时
		config.setBlockWhenExhausted(false);
		//在获取连接的时候检查有效性
		config.setTestOnBorrow(true);
		//指定要连接的Master节点名称（由于一个sentinel可以同时监控多个Master-Slave集群，一个Master-Salve集群包含一个Master节点，所以此处需要指定要连接到哪个Master节点）
		String masterName = "mymaster";
		//Sentinel也支持集群
		Set<String> sentinels = new HashSet<String>();  
		sentinels.add("10.110.20.146:26379");  
		pool = new JedisSentinelPool(masterName, sentinels,config);  
	}

	public static Jedis getConnection() {
		Jedis jedis = pool.getResource();
		return jedis;
	}

	public static void main(String[] args) {
		Jedis jedis = getConnection();
		Map<String, String> value = jedis.hgetAll("apis");
		System.out.println(value);
		jedis.close();
	}
}

以下摘自：http://doc.redisfans.com/topic/sentinel.html

 运行一个 Sentinel 所需的最少配置如下所示：

第一行配置指示 Sentinel 去监视一个名为 mymaster（实际上就是在此处为127.0.0.1 6379起了个名字，方便区分和引用） 的主服务器， 这个主服务器的 IP 地址为 127.0.0.1 ， 端口号为 6379 ， 而将这个主服务器判断为失效至少需要 2 个 Sentinel 同意 （只要同意 Sentinel 的数量不达标，自动故障迁移就不会执行）。

不过要注意， 无论你设置要多少个 Sentinel 同意才能判断一个服务器失效， 一个 Sentinel 都需要获得系统中多数（majority） Sentinel 的支持， 才能发起一次自动故障迁移， 并预留一个给定的配置纪元 （configuration Epoch ，一个配置纪元就是一个新主服务器配置的版本号）。

换句话说， 在只有少数（minority） Sentinel 进程正常运作的情况下， Sentinel 是不能执行自动故障迁移的。

其他选项的基本格式如下：

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

各个选项的功能如下：

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

如果服务器在给定的毫秒数之内， 没有返回 Sentinel 发送的 PING 命令的回复， 或者返回一个错误， 那么 Sentinel 将这个服务器标记为主观下线（subjectively down，简称 SDOWN ）。

不过只有一个 Sentinel 将服务器标记为主观下线并不一定会引起服务器的自动故障迁移： 只有在足够数量的 Sentinel 都将一个服务器标记为主观下线之后， 服务器才会被标记为客观下线（objectively down， 简称 ODOWN ）， 这时自动故障迁移才会执行。

将服务器标记为客观下线所需的 Sentinel 数量由对主服务器的配置决定。

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

如果从服务器被设置为允许使用过期数据集（参见对 redis.conf 文件中对 slave-serve-stale-data 选项的说明）， 那么你可能不希望所有从服务器都在同一时间向新的主服务器发送同步请求， 因为尽管复制过程的绝大部分步骤都不会阻塞从服务器， 但从服务器在载入主服务器发来的 RDB 文件时， 仍然会造成从服务器在一段时间内不能处理命令请求： 如果全部从服务器一起对新的主服务器进行同步， 那么就可能会造成所有从服务器在短时间内全部不可用的情况出现。

你可以通过将这个值设为 1 来保证每次只有一个从服务器处于不能处理命令请求的状态。

Redis主从集群的Sentinel配置

https://www.cnblogs.com/LiZhiW/p/4851631.html