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实例的侦听端口.