开发者学堂课程【Redis 数据库入门：Redis_集群_主从模式_哨兵模式_3】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/15/detail/60
Redis_集群_主从模式_哨兵模式_3
内容介绍：
一、Sentinel 配置文件
二、Sentinel配置举例
一、Sentinel 配置文件
（1）至少包含监控配置选项，用于指定被监控 Master 的相关信息；
（2）Sentinel monitor <name> <ip> <port> <quorum>，例如：Sentinel monitor mymaster 127.0.0.1 6379 2，监视 mymaster 的 主服务器，服务器IP和端口将主服务器判断为下线失效至少需要两个 Sentinel 同意，如果多数Sentinel同意才会执行故障转移。
（3）Sentinel 会根据 Master 配置自动发现 Master 的 Slaves。也就是说，在Sentinel 的配置文件里，只需要写入一条命令Sentinel monitor <name> <ip> <port> <quorum>，而不需要想从服务器。从“服务器下线后重新上线后”的示意图中可以观察到，Sentinel 除了监控 Master，还监控 Slave，但是不会配置 Slave,因为哪些 Slave 注册到 Master 上时，Master可以监控的，Sentinel 连接 Master 即可获得 Slave 的信息 entinel 只需要配置主服务器就可以了。
（4）Sentinel 默认端口号为26379。
6379是不是很熟悉，默认上涨2万。如果 Master 的端口是6379，那它就会占用当前的服务器端口26371，如果 Master 的端口是6380，那它就会占用当前的服务器端口26380。当然我们要启用多个端口。
二、Sentinel配置举例
1.要求
执行以下命令，创建两个监视主服务器s1的 Sentinel 实例：
（1）$redis-sentinel sentinel 1.conf
（2）$redis-sentinel sentinel 2.conf
（3）其中 sentinel 1.conf 的内容为 :
port 26379
Sentinel monitor s1 127.0.0.1 6379 2
（4）sentinel 2.conf 的内容为 :
port 26380
Sentinel monitor s1 127.0.0.1 6380 2
2、基本思路
（1）按要求需要创建一个或多个 Sentinel.conf 文件；
（2）文件中为其配置好端口，通常在端口上加2万；
（3）为 Sentinel 写入Sentinel monitor <name> <ip> <port> <quorum> 格式的配置。
如下图：
3、操作
在3台机器里面的 Redis 搭建真正的主从结构（当然一台机里也可以做），即一个Master 和两个 Slave。
（1）首先输入service redisd start 将端口为6379的Redis启动，输入“open”登录，输入redis-cli，并输入 slaveof 127.0.0.16380在其上注册一个从服务器。查询其配置可以发现“Synchronization with slave 127.0.0.1:6379 succeeded”，即在主服务器上成功注册了端口为6379的从服务器。
（2）将整个主从搭好之后，接下来搭建 Sentinel。每台机器里都有一个哨兵，二每个 Redis 服务都配一个哨兵没有必要。此时，一台机器里面分别有三个6379、6380和6381三个Redis服务。脚本中的意思是期望大家用三台机器，里面的端口都可以是6379，每台机器里面都放 Sentinel。课上演示为一台机里放三个 Redis 服务，放三个 Sentinel。事实上，若有N台机器，每台机器里有四个 Redis，即共有4N个 Redis，也就是需要N个 Sentinel。也就是说每台机器里面有一个哨兵就可以了。
①创建配置文件。该种情况下搭建一个 Sentinel 也可以完成任务，不过相对来说3个更好，因为3个高可用性更高。输入:
vim sentinel.conf
port 26379
Sentinel monitor bjsxt 127.0.0.1 6380 1
因为现在只有1个 Sentinel，所以在投票过程中只要有1票就可以认为主服务器下线失效，将其保存退出。
②启动Sentinel。输入：
redis-sentinel sentinel 1.conf
或
redis-server sentinel 1.conf --sentinel 1
两者是等价，点击回车。在日志文件中可以看到，该端口是26379；”monitor master bjsxt 127.0.0.1 6380 quorum 1”表示 sentinel 1开始监控了主从集群，监控了6380，发现了两个 Slave 6381和6379。此时的这一个哨兵就可以进行监控了。
③停掉 Master，观察 Slave 是否会提升为 Master。停掉6380之后，待 sentinel 1监控到 Master 6380下线。
日志中显示“+odown master bjsxt 127.0.0.1 6380 #quorum 1/1”，即sentinel 1投了一票，而仅有一个 sentinel ，因此投了一票之后，它试图去做故障解决、恢复（try -failover masterbjsxt 127.0.0.1 6380），并给新的 leader 偷了一票（vote-for-leader）。
然后“switch-master bjsxt 127.0.0.1 6380 127.0.0.1 6381”将6381提升成为新的Master，并试图将6379和6380提升为6381的 Slave，但是结果显示“+odown master bjsxt 127.0.0.1:6380 127.0.0.1:6380 @bjsxt 127.0.0.1 6381”，即6380已经下线。
连接6381的时候，配置软件中显示Synchronization with slave 127.0.0.1:6379 succeeded”，即6379成为了6381的Slave。
③为新的 master 6381设置数据。如输入:set newkey 1234567890，此时查询6379中是否有 newkey 的数据。在6379中输入keys*，结果显示已经包含了“newkey”的数据；再输入get newkey查询其值，结果显示为“1234567890”，说明数据同步成功。
自行搭建的时候可以搭建三个哨兵，投票时的日志惠誉课堂上的演示略微不同。
如投票是的结果显示是2/3，就会执行下面 failover 故障解决。投票的过程中系统可能会有延迟，这是因为当将 Master 下线之后，哨兵去检测 Master 的运行状态需要一定时间，这个时间就是延迟时间。
大部分情况下的 Redis 集群我们直接用主从复制加哨兵就可以满足一般需求了，因为哨兵做到了高可用，而且是热备的高可用。主从做到了读写分离，而且可以有多个 Slave，因此读的复杂被均衡了。只不过在写命令方面还有些问题，因为只有Master 才能写命令。
所以在实际应用过程中，如果写命令也需要做更多的集群分担压力的，那主从复制加哨兵性能效率就会收到影响，但一般情况下这种集群模式就可以满足大部分的需求。
