Redis主从、哨兵模式的搭建

壹、Redis主从分离

准备三个redis配置文件（redis.conf），分别修改为redis6380.conf、redis6381.conf、redis6382.conf

一、配置Master

1、修改端口

# Accept connections on the specified port, default is 6379 (IANA #815344).
# If port 0 is specified Redis will not listen on a TCP socket.
port 6380

　　redis 的默认端口是6379，这里我们把主服务器的端口设置为6380

　2、修改pidfile

# If a pid file is specified, Redis writes it where specified at startup
# and removes it at exit.
#
# When the server runs non daemonized, no pid file is created if none is
# specified in the configuration. When the server is daemonized, the pid file
# is used even if not specified, defaulting to "/var/run/redis.pid".
#
# Creating a pid file is best effort: if Redis is not able to create it
# nothing bad happens, the server will start and run normally.
pidfile /var/run/redis_6380.pid

　　pidfile 是我们启动redis 的时候，linux 为我们分配的一个pid 进程号，如果这里不作修改，会影响后面redis服务的启动

二、配置Slave

和上面配置 master一样，我们需要修改端口号和pid 文件，分别为6380和6381，在修改完之后，有两种方法配置从服务

1、在配置文件中配置从服务

     先修改6381的配置

################################# REPLICATION #################################
#
# slaveof <masterip> <masterport>

slaveof 127.0.0.1 6380

　可以在配置文件中直接修改 slaveof 属性，我们直接配置主服务器的ip 地址，和端口号，如果这里主服务器有配置密码

　可以通过配置masterauth 来设置链接密码

# If the master is password protected (using the "requirepass" configuration
# directive below) it is possible to tell the slave to authenticate before
# starting the replication synchronization process, otherwise the master will
# refuse the slave request.
#
# masterauth <master-password>　　 

启动redis 服务：

可以看到，现在有两个现在在运行，分别进入6380、6381的客户端，看一下状态

可看到主从的信息，6381是个从服务的角色，连着主服务6380

　2、在服务启动后设置

　　  修改6382端口的服务器配置文件之后，启动服务

进入6382客户端，查看当前服务状态

可以看到，当前服务器的状态时作为一个主服务的角色在运行，我们接下来修改他的状态，在其客户端使用命令 ：slaveof 127.0.0.1 6380

修改后，查看其状态，其作为6380的一个从服务

接下来，查看目前master(6380)服务的状态，其从服务变为6381和6382

可以看到，两个从服务已经在连着主服务器，上面两种配置的区别在于，当salve 断线重连之后，

　  如果我们是修改类配置文件，重连之后会自己链接上去master，并且同步master 上面的数据，

　  如果我们是手动连接上去的主服务器，重连之后，从服务器会读取自己本地的 rdb 回复数据，而不会去自动链接主服务

在master上插入键值数据后在slave上可以获取到，主从同步正常，slave上只能查看，不能进行写操作，以免破坏数据的一致性

三、总结

如果在主从复制架构中出现宕机的情况，需要分情况看：

1、 从Redis宕机

这个相对而言比较简单，在Redis中从库重新启动后会自动加入到主从架构中，自动完成同步数据；

2、 主Redis宕机

a) 这个相对而言就会复杂一些，需要以下2步才能完成

i.   第一步，在从数据库中执行SLAVEOF NO ONE命令，断开主从关系并且提升为主库继续服务；

ii.   第二步，将主库重新启动后，执行SLAVEOF命令，将其设置为其他库的从库，这时数据就能更新回来；

b)  这个手动完成恢复(人工介入)的过程其实是比较麻烦的并且容易出错，有没有好办法解决呢？当前有的，Redis提供的哨兵（sentinel）的功能。

贰、Sentinel 哨兵

redis的哨兵机制是redis2.8开始支持，而集群模式是redis3.0开始支持。

redis的sentinel系统用于管理多个redis服务器，该系统主要执行三个任务：监控、提醒、自动故障转移。

1、监控（Monitoring）： Redis Sentinel实时监控主服务器和从服务器运行状态，并且实现自动切换。

2、提醒（Notification）：当被监控的某个 Redis 服务器出现问题时， Redis Sentinel 可以向系统管理员发送通知， 也可以通过 API 向其他程序发送通知。

3、自动故障转移（Automatic failover）： 当一个主服务器不能正常工作时，Redis Sentinel 可以将一个从服务器升级为主服务器， 并对其他从服务器进行配置，让它们使用新的主服务器。当应用程序连接Redis 服务器时， Redis Sentinel会告之新的主服务器地址和端口。

1、配置端口

　　在sentinel.conf 配置文件中， 我们可以找到port 属性，这里是用来设置sentinel 的端口，一般情况下，至少会需要三个哨兵对redis 进行监控，我们可以通过修改端口启动多个sentinel 服务。

3个sentinel节点(sentinel-26380.conf、sentinel-26381.conf、sentinel-26382.conf)的部署方法完全是一致的(端口不同),下面以sentinel-26380.conf节点的部署为例子

# port <sentinel-port>
# The port that this sentinel instance will run on
port 26380

　2、配置主服务器的ip 和端口

　　我们把监听的端口修改成6380，并且加上权值为2，这里的权值，是用来计算我们需要将哪一台服务器升级升主服务器

　　监控mymaster主服务器，服务器ip和端口，将这个主服务器判断为下线失效至少需要2个Sentinel同意，如果多数Sentinel同意才会执行故障转移，Sentinel会根据Master的配置

　　自动发现Master的Slaves

3、启动Sentinel

启动redis-sentinel 程序， 可以用redis提供的命令来启动：./redis-sentinel sentinel-26380.conf &

可进入redis的各自客户端使用命令info replication 查看服务状态

4、关闭Master

　　手动关闭Master之后，sentinel 在监听master 确实是断线了之后，将会开始计算权值，然后重新分配主服务器

可以看到，6380主服务器断了之后，sentinel 帮我们选了6382作为新的主服务器

进到6382的客户端，查看状态：

可以看到 6382，从slave 荣升为master

原本的没有权限写，也得到了相应的权限

5、重连Master

　 如果master 重连之后，会不会抢回属于他的位置，答案是否定的，因此当master 回来之后，他也只能当个从服务

启动原master 6380，查看其状态，是作为6382的从服务的存在

6.Sentinel 总结

　　一、Sentinel的作用：

　　　1)、Master 状态监测
　　　2)、如果Master 异常，则会进行Master-slave 转换，将其中一个Slave作为Master，将之前的Master作为Slave
　　　3)、Master-Slave切换后，master_redis.conf、slave_redis.conf和sentinel.conf的内容都会发生改变，即master_redis.conf中会多一行slaveof的配置，sentinel.conf的监控目标会随之调换

　　二、Sentinel的工作方式:

　　1)：每个Sentinel以每秒钟一次的频率向它所知的Master，Slave以及其他 Sentinel 实例发送一个 PING 命令 
　　2)：如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 则这个实例会被 Sentinel 标记为主观下线。 
　　3)：如果一个Master被标记为主观下线，则正在监视这个Master的所有 Sentinel 要以每秒一次的频率确认Master的确进入了主观下线状态。 
　　4)：当有足够数量的 Sentinel（大于等于配置文件指定的值）在指定的时间范围内确认Master的确进入了主观下线状态， 则Master会被标记为客观下线 
　　5)：在一般情况下， 每个 Sentinel 会以每 10 秒一次的频率向它已知的所有Master，Slave发送 INFO 命令 
　　6)：当Master被 Sentinel 标记为客观下线时，Sentinel 向下线的 Master 的所有 Slave 发送 INFO 命令的频率会从 10 秒一次改为每秒一次 
　　7)：若没有足够数量的 Sentinel 同意 Master 已经下线， Master 的客观下线状态就会被移除。 
　　　　若 Master 重新向 Sentinel 的 PING 命令返回有效回复， Master 的主观下线状态就会被移除。