Redis主从复制架构搭建以及容灾部署哨兵机制
一、redis主从复制的好处
1、避免Redis单点故障；
2、构建读写分离架构，满足读多写少的应用场景；
二、主从架构搭建
1、Redis主从不需要安装多个Redis,只需复制多个配置文件（redis.conf）,修改即可。所以如果要进行主从结构搭建,需先安装单机版Redis 单机版。
2、安装完单机版redis后
#进入到redis安装目录
cd /usr/local/src/soft/redis-5.0.3
#创建6379、6380、6381文件夹
mkdir 6379
mkdir 6380
mkdir 6381
#将redis.conf分别拷进6379、6380、6381文件夹
cp redis.conf 6379/6379.conf
cp redis.conf 6380/6380.conf
cp redis.conf 6381/6381.conf
3、修改配置文件（除以下配置，其他同单机版redis配置，参考：）
#修改pidfile指向路径
pidfile "/usr/local/src/soft/redis-5.0.3/6379/redis_6379.pid"
#6380和6381配置修改同6379
4、设置redis的主从关系
两种方式：
4.1 在6380.conf和6381.conf中设置slaveof
slaveof
4.2 使用redis-cli客户端连接redis-server后，执行slaveof命令（重启后主从关系会失效）
slaveof
5、启动redis服务
./redis-server ../6379/6379.conf
./redis-server ../6380/6380.conf
./redis-server ../6381/6381.conf
6、查看redis的主从关系
#使用客户端连接6379端口
./redis-cli -h 192.168.200.131 -p 6379
192.168.200.131:6379> info replication
7、测试
主库写入数据，从库读取数据
8、主从复制原理
1.当从库和主库建立MS关系后,会向主数据库发送SYNC命令
2.主库接收到SYNC命令后会开始在后台保存快照(RDB持久化过程),并将期间接收到的写命令缓存起来
3.当快照完成后,主Redis会将快照文件和所有缓存的写命令发送给从Redis
4.从Redis接收到后,会载入快照文件并且执行收到的缓存的命令
5.之后,主Redis每当接收到写命令时就会将命令发送从Redis，从而保证数据的一致
三、容灾部署哨兵
1、在redis的主从架构可用的前提下
#进入redis的安装目录
cd /usr/local/src/soft/redis-5.0.3
#复制sentinel.conf配置文件
cp sentinel.conf 6379/sentinel_26379.conf
cp sentinel.conf 6380/sentinel_26380.conf
cp sentinel.conf 6381/sentinel_26381.conf
2、修改哨兵配置文件（以sentinel_26379.conf为例）
#关闭保护模式
protected-mode no
#端口号
port 26379
#开启后台运行
daemonize yes
#日志文件路径
logfile "/usr/local/src/soft/redis-5.0.3/6379/sentinel_26379.log"
#工作目录
dir "/usr/local/src/soft/redis-5.0.3/6379"
#监控主数据库
sentinel monitor redis-master 192.168.200.131 6379 2
#主数据库的名称、密码
sentinel auth-pass redis-master 123456
注：sentinel_26380.conf、sentinel_26381.conf 依次按照上述修改
说明：
redis-master:监控主数据的名称,自定义即可,可以使用大小写字母和“.-_”符号
192.168.200.131:监控的主数据库的IP
6379:监控的主数据库的端口
2:最低通过票数
3、启动哨兵实例
./redis-sentinel ../6379/sentinel_26379.conf
./redis-sentinel ../6380/sentinel_26380.conf
./redis-sentinel ../6381/sentinel_26381.conf
4、查看哨兵信息
#客户端连接26379端口
./redis-cli -h 192.168.200.131 -p 26379
#查看
info sentinel
5、测试哨兵是否正常工作
5.1查看所有redis的进程
5.2 杀掉主库的进程
kill -9 1765
5.3 查看新的主从架构
5.4重启刚刚停掉的服务后，查看主从架构信息
6.哨兵日志（主库日志）
7、哨兵原理
首先解释2个名词:SDOWN和ODOWN.
SDOWN:subjectively down,直接翻译的为”主观”失效,即当前sentinel实例认为某个redis服务为”不可用”状态.
ODOWN:objectively down,直接翻译为”客观”失效,即多个sentinel实例都认为master处于”SDOWN”状态,那么此时master将处于ODOWN,ODOWN可以简单理解为master已经被集群确定为”不可用”,将会开启failover
SDOWN与ODOWN转换过程:
i.每个sentinel实例在启动后,都会和已知的slaves/master以及其他sentinels建立TCP连接,并周期性发送PING(默认为1秒),在交互中,如果redis-server无法在”down-after-milliseconds”时间内响应或者响应错误信息,都会被认为此redis-server处于SDOWN状态.
ii.SDOWN的server为master,那么此时sentinel实例将会向其他sentinel间歇性(一秒)发送”is-master-down-by-addr ”指令并获取响应信息,如果足够多的sentinel实例检测到master处于SDOWN,那么此时当前sentinel实例标记master为ODOWN…其他sentinel实例做同样的交互操作.配置项”sentinel monitor ”,如果检测到master处于SDOWN状态的slave个数达到,那么此时此sentinel实例将会认为master处于ODOWN.
每个sentinel实例将会间歇性(10秒)向master和slaves发送”INFO”指令,如果master失效且没有新master选出时,每1秒发送一次”INFO”;”INFO”的主要目的就是获取并确认当前集群环境中slaves和master的存活情况.
经过上述过程后,所有的sentinel对master失效达成一致后,开始failover.
Sentinel与slaves”自动发现”机制:
在sentinel的配置文件中,都指定了port,此port就是sentinel实例侦听其他sentinel实例建立链接的端口.在集群稳定后,最终会每个sentinel实例之间都会建立一个tcp链接,此链接中发送”PING”以及类似于”is-master-down-by-addr”指令集,可用用来检测其他sentinel实例的有效性以及”ODOWN”和”failover”过程中信息的交互.在sentinel之间建立连接之前,sentinel将会尽力和配置文件中指定的master建立连接.sentinel与master的连接中的通信主要是基于pub/sub来发布和接收信息,发布的信息内容包括当前sentinel实例的侦听端口.