Redis 利用 哨兵模式 实现一主二从三哨兵架构
一、redis环境：
环境：redis6.2.6
linux虚拟机一台，contos7；
二、哨兵介绍：
1.一主二从三哨兵理论图：
一主两从三哨兵集群，当master节点宕机时，通过哨兵(sentinel)重新推选出新的master节点，保证集群的可用性。
2.哨兵的主要功能：
1.集群监控：负责监控 Redis master 和 slave 进程是否正常工作。
2.消息通知：如果某个 Redis 实例有故障，那么哨兵负责发送消息作为报警通知给管理员。
3.故障转移：如果 master node 挂掉了，会自动转移到 slave node 上。
4.配置中心：如果故障转移发生了，通知 client 客户端新的 master 地址。
PS：根据推举机制，集群中哨兵数量最好为奇数(3、5…)
3.哨兵用于实现 redis 集群的高可用，本身也是分布式的，作为一个哨兵集群去运行，互相协同工作。
- 故障转移时，判断一个 master node 是否宕机了，需要大部分的哨兵都同意才行，涉及到了分布式选举的问题。
- 即使部分哨兵节点挂掉了，哨兵集群还是能正常工作的，因为如果一个作为高可用机制重要组成部分的故障转移系统本身是单点的，那就很坑爹了。
4.哨兵的核心知识：
- 哨兵至少需要 3 个实例，来保证自己的健壮性。
- 哨兵 + redis 主从的部署架构，是不保证数据零丢失的，只能保证 redis 集群的高可用性。
- 对于哨兵 + redis 主从这种复杂的部署架构，尽量在测试环境和生产环境，都进行充足的测试和演练。
三、安装redis:
此处省略redis的安装。
四、使用Redis主从复制的作用：
主从复制，是指将一台Redis主节点服务器的数据，复制到其他的Redis从节点服务器。
主节点称为(master/leader)，从节点称为(slave/follower)；
1，数据冗余：主从复制实现了数据的热备份，这也是持久化实现的另一种方式。
2，故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。
3，读写分离：master服务主要用来写，slave服务主要用来读数据。可以提高服务器的负载能力，可以根据需求的变化，添加从节点的数量。
4，负载均衡：同时配合读写分离，由主节点提供写服务，从节点提供读服务，分担服务器的负载。在写少读多的情况下，通过多个从节点分担读负载，能够大大提高Redis服务的并发量和负载。
5，高可用的基石，主从复制是哨兵和集群模式能够实施的基础。
五、配置redis一主二从：
在正常的生产中我们是准备多台服务器，比如三台，每台都在各自的linux系统中安装redis。
但是此处为了演示方便，我使用一台电脑安装虚拟机，在虚拟机上安装三份redis服务，来模拟一主二从的效果。
第一步：修改原redis.conf配置文件：
redis.conf配置文件采用默认的混合持久化，也可以采用单独的RDB持久化，因为主从复制的本质是RDB方式，所以要有RDB方式参与即可。
原redis.conf配置文件需要修改的几个地方：
2.同样我们要将后台运行打开：daemonize no，设置为yes。
3.将 保护模式关闭：protected-mode yes 改为：protected-mode no
4.打开RDB持久化配置：
#RDB持久化策略 默认三种方式，[900秒内有1次修改],
#[300秒内有10次修改],[60秒内有10000次修改]即触发RDB持久化，
#我们可以手动修改该参数或新增策略
save 900 1
save 300 10
save 60 10000
#RDB文件名
dbfilename dump.rdb
#RDB文件存储路径
dir ./
策略配置：
#在seconds秒内有changes次数据修改就触发RDB持久化
5.开启AOF持久化配置
appendonly yes
#AOF文件名
appendfilename “appendonly.aof”
#AOF文件存储路径 与RDB是同一个参数,共用一个文件路径
dir ./ #即bin目录下
#AOF策略，一般都是选择第一种[always:每个命令都记录],
#[everysec:每秒记录一次],[no:看机器的心情高兴了就记录，linux一般半个小时同步一次]
#appendfsync always
appendfsync everysec
# appendfsync no
#aof文件大小比起上次重写时的大小,增长100%(配置可以大于100%)时,触发重写。
#[假如上次重写后大小为10MB，当AOF文件达到20MB时也会再次触发重写，以此类推
auto-aof-rewrite-percentage 100
#aof文件大小超过64MB*2时,触发重写，
#为何要乘以2，因为auto-aof-rewrite-percentage 100 是翻倍即100%，
#达到翻倍时才重写
auto-aof-rewrite-min-size 64mb
6.打开混合持久化：
#6.aof-use-rdb-preamble yes # 检查混合持久化是否打开，redis5.0后默认开启
第二步：将修改后的redis.conf配置文件复制出来三份：
ll #查看文件夹内容
cp redis.conf redis_bk.conf #尽量备份一个配置文件，防止修改错了，可以重新用
cp redis.conf redis6379.conf
cp redis.conf redis6380.conf
cp redis.conf redis6381.conf
第三步：分别修改三个配置文件：
修改的内容：
pidfile /var/run/redis_6379.pid
port 6379
dbfilename dump6379.rdb
修改的内容：
pidfile /var/run/redis_6380.pid
port 6380
dbfilename dump6380.rdb
修改的内容：
pidfile /var/run/redis_6381.pid
port 6381
dbfilename dump6381.rdb
redis启动前的准备工作：
查看虚拟机防火墙是否关闭，需要关闭防火墙
1:查看防火状态
service iptables status
2:暂时关闭防火墙
service iptables stop
3:永久关闭防火墙
chkconfig iptables off
关闭后再查看防火墙状态
开放指定端口6379：
开放指定端口的方式一：
在linux中执行： /sbin/iptables -I INPUT -p tcp –dport 6379 -j ACCEPT
redis默认端口号6379是不允许进行远程连接的，所以在防火墙中设置6379开启远程服务；
开放指定端口的方式二：
先开启防火墙才能开放指定端口的：systemctl start firewalld
firewall-cmd –zone=public –add-port=6379/tcp –permanent
第四步：启动三台redis服务器,并查看是否启动成功：
redis-server redis6380.conf
redis-server redis6381.conf
ps -ef | grep redis
第五步：配置从库不配置主库 ：
先连接上redis客户端：
然后将6380机器配置成从机：
#slaveof 127.0.0.1 6379
info replication
然后将6381机器配置成从机：
#slaveof 主机ip 主机端口号
slaveof 127.0.0.1 6379
info replication
在主机查看从机信息：发现配置成功。
info replication
六、配置redis三哨兵：
将官方自带的sentinel.conf(此文件在redis的源码目录下，即解压路径下）复制到/usr/local/bin：
然后复制出来三份：
修改的内容如下：
文件修改内容如下：
protected-mode no
daemonize yes
port 26379 #sentinel 端口
dir “/usr/local/bin”
sentinel monitor mymaster 127.0.0.1 6379 2
然后分别修改sentinel1.conf信息如下：
daemonize yes
port 26380 # sentinel 端口，因为我们在一台虚拟机上，所以端口要不一样
dir “/usr/local/bin”
sentinel monitor mymaster 127.0.0.1 6379 2 #这里的mymaster 两个副本的要一样,mymaster同一个主机名
然后分别修改sentinel2.conf信息如下：
daemonize yes
port 26381 # sentinel 端口，因为我们在一台虚拟机上，所以端口要不一样
dir “/usr/local/bin”
sentinel monitor mymaster 127.0.0.1 6379 2 #这里的mymaster 两个副本的要一样
配置文件详解
哨兵的配置主要就是修改sentinel.conf配置文件中的参数，在Redis安装目录即可看到此配置文件，各参数详解如下:
port 26379
# 哨兵sentinel的工作目录
dir ./
# 是否开启保护模式，默认开启。
protected-mode:no
# 是否设置为后台启动。
daemonize:yes
# 哨兵sentinel的日志文件
logfile:./sentinel.log
# 哨兵sentinel监控的redis主节点的
## ip：主机ip地址
## port：哨兵端口号
## master-name：可以自己命名的主节点名字
## quorum:当这些quorum个数sentinel哨兵认为master主节点失联 那么这时
#客观上认为主节点失联了
# sentinel monitor <master-name> <ip> <redis-port> <quorum>
sentinel monitor mymaster 127.0.0.1 6379 2
# 当在Redis实例中开启了requirepass，所有连接Redis实例的客户端都要提供密码。
# sentinel auth-pass <master-name> <password>
sentinel auth-pass mymaster 123456
# 指定主节点应答哨兵sentinel的最大时间间隔，超过这个时间，哨兵主观上认为主节点下线，
#默认30秒
# sentinel down-after-milliseconds <master-name> <milliseconds>
sentinel down-after-milliseconds mymaster 30000
# 指定了在发生failover主备切换时，最多可以有多少个slave同时对新的master进行同步。
#这个数字越小，完成failover所需的时间就越长；反之，但是如果这个数字越大，就意味着
#越多的slave因为replication而不可用。可以通过将这个值设为1，来保证每次只有一个slave，
#处于不能处理命令请求的状态。
# sentinel parallel-syncs <master-name> <numslaves>
sentinel parallel-syncs mymaster 1
# 故障转移的超时时间failover-timeout，默认三分钟，可以用在以下这些方面：
## 1. 同一个sentinel对同一个master两次failover之间的间隔时间。
## 2. 当一个slave从一个错误的master那里同步数据时开始，直到slave被纠正为从正确
#的master那里同步数据时结束。
## 3. 当想要取消一个正在进行的failover时所需要的时间。
## 4.当进行failover时，配置所有slaves指向新的master所需的最大时间。不过，
#即使过了这个超时，slaves依然会被正确配置为指向master，
但是就不按parallel-syncs所配置的规则来同步数据了
# sentinel failover-timeout <master-name> <milliseconds>
sentinel failover-timeout mymaster 180000
# 当sentinel有任何警告级别的事件发生时（比如说redis实例的主观失效和客观失效等等），
#将会去调用这个脚本。一个脚本的最大执行时间为60s，如果超过这个时间，
#脚本将会被一个SIGKILL信号终止，之后重新执行。
# 对于脚本的运行结果有以下规则：
## 1. 若脚本执行后返回1，那么该脚本稍后将会被再次执行，重复次数目前默认为10。
## 2. 若脚本执行后返回2，或者比2更高的一个返回值，脚本将不会重复执行。
## 3. 如果脚本在执行过程中由于收到系统中断信号被终止了，则同返回值为1时的行为相同。
# sentinel notification-script <master-name> <script-path>
sentinel notification-script mymaster /var/redis/notify.sh
# 这个脚本应该是通用的，能被多次调用，不是针对性的。
# sentinel client-reconfig-script <master-name> <script-path>
sentinel client-reconfig-script mymaster /var/redis/reconfig.sh
最后是先启动三个服务，然后起送三个哨兵，然后客户端；
启动哨兵：
redis-sentinel sentinel1.conf
redis-sentinel sentinel2.conf
启动后查看sentinel信息：redis-cli -p sentinel的端口号
info sentinel
