在第二篇中使用2.8.17搭建了主从复制，但是它存在Master单点问题，为了解决这个问题，Redis从2.6开始引入sentinel，用于监控和管理Redis的主从复制环境，进行自动failover，即Master挂了后，sentinel自动从从服务器选出一个Master使主从复制集群仍然可以工作，如果Master醒来再次加入集群，只能以从服务器的形式工作。
什么是Sentinel
Redis Sentinel is a system designed to help managing Redis instances. It performs the following four tasks- Monitoring. Sentinel constantly checks if your master and slave instances are working as expected.
- Notification. Sentinel can notify the system administrator, or another computer program, via an API, that something is wrong with one of the monitored Redis instances.
- Automatic failover. If a master is not working as expected, Sentinel can start a failover process where a slave is promoted to master, the other additional slaves are reconfigured to use the new master, and the applications using the Redis server informed about the new address to use when connecting.
- Configuration provider. Sentinel acts as a source of authority for clients service discovery: clients connect to Sentinels in order to ask for the address of the current Redis master responsible for a given service. If a failover occurs, Sentinels will report the new address.
Redis主从复制搭建步骤
Redis搭建主从复制的步骤十分简单，以下在Windows上操作。
1. 解压Redis压缩包至E:\devsoftware\redis-2.8.17
2.在Redis目录中复制两份redis.windows.conf，分别命名为redis.windows.conf.slave1,redis.windows.conf.slave2
3.修改redis.conf.slave1文件，
- port 6379 改为 port 6380
- 打开slaveof指令，改为slaveof 127.0.0.1 6379
- 将快照文件名改为dbfilename dump.slave1.rdb
- 如果使用AOF方式持久化，则需要将appendfilename appendonly.aof改为appendfilename appendonly.slave1.aof
4. 修改redis.conf.slave2文件
- port 6379 改为 port 6381
- 打开slaveof指令，改为slaveof 127.0.0.1 6379
- 将快照文件名改为dbfilename dump.slave2.rdb
- 如果使用AOF方式持久化，则需要将appendfilename appendonly.aof改为appendfilename appendonly.slave2.aof
5. 启动三个Redis服务器，形成一主两从的主从复制副本集
通过上面的启动过程，可见只需要redis-server一个启动脚本即可，它读取不同的配置文件，来完成初始化
- Master启动时的日志输出
[21684] 25 Nov 20:54:16 * Slave ask for synchronization [21684] 25 Nov 20:54:16 * Starting BGSAVE for SYNC [21684] 25 Nov 20:54:16 * Foregroud saving started by pid 21684 [21684] 25 Nov 20:54:17 * DB saved on disk [21684] 25 Nov 20:54:17 * Background saving terminated with suc [21684] 25 Nov 20:54:17 * Synchronization with slave succeeded
- Slave1启动时的日志输出
[21068] 25 Nov 20:54:15 * Server started, Redis version 2.4.5 [21068] 25 Nov 20:54:15 * DB loaded from disk: 0 seconds [21068] 25 Nov 20:54:15 * The server is now ready to accept connections on port [21068] 25 Nov 20:54:16 - DB 0: 1 keys (0 volatile) in 4 slots HT. [21068] 25 Nov 20:54:16 - 0 clients connected (0 slaves), 1180024 bytes in use [21068] 25 Nov 20:54:16 * Connecting to MASTER... [21068] 25 Nov 20:54:16 * MASTER <-> SLAVE sync started [21068] 25 Nov 20:54:16 * Non blocking connect for SYNC fired the event. [21068] 25 Nov 20:54:17 * MASTER <-> SLAVE sync: receiving 19 bytes from master [21068] 25 Nov 20:54:17 * MASTER <-> SLAVE sync: Loading DB in memory [21068] 25 Nov 20:54:17 * MASTER <-> SLAVE sync: Finished with success
Redis sentinel 搭建步骤
- 创建sentinel服务器的配置文件,sentinel.conf文件，内容如下
port 26389 sentinel monitor mymaster 127.0.0.1 6379 1 sentinel down-after-milliseconds mymaster 10000 sentinel failover-timeout mymaster 180000 sentinel parallel-syncs mymaster 1特别注意，在2.6版本还需要额外设置一个属性sentinel can-failover mymaster yes，在2.8版本无需设置这个属性，设置了反而不能启动sentinel服务器
1. down-after-milliseconds
master被当前sentinel实例认定为“失效”(SDOWN)的间隔时间
2. failover-timeout
failover过期时间，当failover开始后，在此时间内仍然没有触发任何failover操作，当前sentinel 将会认为此次failoer失败
3. parallel-syncs
当新master产生时，同时进行slaveof到新master并进行同步复制的slave个数,也就是同时几个slave进行同步。因为在salve执行salveof与新master同步时，将会终止客户端请求，因此这个值需要权衡。此值较大，意味着“集群”终止客户端请求的时间总和和较大，此值较小,意味着“集群”在故障转移期间，多个salve向客户端提供服务时仍然使用旧数据
- 启动sentinel服务器
使用如下命令启动sentinel服务器
redis-server.exe sentinel.conf --sentinel
- 经过数据同步后，sentinel监测到当前的系统当前有一主两从环境，使用如下命令可以观察到sentinel的状态
redis-cli.exe -h 127.0.0.1 -p 26389 info sentinel
得到如下结果，结果表明，当前的master监听端口是6381
E:\devsoftware\redis-2.8.17>redis-cli.exe -h 127.0.0.1 -p 26389 info sentinel # Sentinel sentinel_masters:1 sentinel_tilt:0 sentinel_running_scripts:0 sentinel_scripts_queue_length:0 master0:name=mymaster,status=ok,address=127.0.0.1:6381,slaves=2,sentinels=1
主服务器写入从服务器读取数据测试
- 往主服务器上写入一个数据，检查从服务器是否同步
E:\devsoftware\redis-2.4.5-win32-win64\64bit>redis-cli.exe -h 127.0.0.1 -p 6379 redis 127.0.0.1:6379> set abc 1 OK redis 127.0.0.1:6379> get abc "1" redis 127.0.0.1:6379>Ctrl + C
- 两个从服务器的读取操作：
E:\devsoftware\redis-2.4.5-win32-win64\64bit>redis-cli.exe -h 127.0.0.1 -p 6380 redis 127.0.0.1:6380> get abc "1" redis 127.0.0.1:6380> ^C E:\devsoftware\redis-2.4.5-win32-win64\64bit>redis-cli.exe -h 127.0.0.1 -p 6381 redis 127.0.0.1:6381> get abc "1" redis 127.0.0.1:6381>
从服务器写入，其它服务器读取数据测试
系统提示，
(error) READONLY You can't write against a read only slave.只读slave不能写入数据，有只读的slave，就应该有可读写的slave的存在。这个看看配置文件，配置文件里有如下指令
slave-read-only yes配置文件对这个指令的注释是，
Since Redis 2.6 by default slaves are read-only. Note: read only slaves are not designed to be exposed to untrusted clients on the internet. It's just a protection layer against misuse of the instance. Still a read only slave exports by default all the administrative commands such as CONFIG, DEBUG, and so forth. To a limited extend you can improve security of read only slaves using 'rename-command' to shadow all the administrative / dangerous commands.
主服务器挂了，是否会自动的从Slave中重新选择Master
1. Q: 在Sentinel的配置文件中，我们看到sentinel只监控了Master，那么那些Slave是如何监测到的呢？ A:Sentinel通过监听Master，知道了Master的存在，那么Sentinel可以读取Master关于Slave的信息，然后交由Sentinel进行管理 2.Q: 在Sentinel的配置文件中，我们看到sentinel只监控了Master,那么那些同一个集群中的Sentinel是如何发现的呢？ 3. Q：当Master挂掉再重启后，将作为Slave加入到集群里，而Master的配置文件中，slaveof指令是没有配置的，也就是说，Master启动时，它自己认为自己将作为Master或者独立的Redis服务器运行，此时，Sentinel如何把它作为Slave加入到集群中的？ A: 老的Master挂掉后，新的Master产生，但是老的Master信息(IP：Port)已然存在于sentinel中，不过它已经不再是Master而是Slave。当Master启动后，Sentinel可以ping到它启动起来了，此时，Sentinel将它的配置文件加了一行，指示它已经成为别人的Slave，如slaveof 127.0.0.1 6381然后通知Master，已经是Slave状态(只要修改用于指示Master/Slave的标示参数即可)