redis 主从配置和哨兵模式

主从配置

• 主节点

复制一份redis.conf成redis-6379.conf。修改配置：
	bind 0.0.0.0
	#后台运行
	daemonize yes
	#pid文件
	pidfile /var/run/redis_6379.pid
	#日志文件
	logfile "6379.log"

之后启动主节点 redis-server redis-6379.conf

• 从节点

复制一份redis.conf成redis-6380.conf。修改配置：
	bind 0.0.0.0
	port 6380
	daemonize yes
	pidfile /var/run/redis_6380.pid
	logfile "6380.log"
	#slaveof表示作为从库的配置
	slaveof 127.0.0.1 6379
	#从库只能读操作
	slave-read-only yes
	#从库连接主库密码
	masterauth <master-password>

启动从节点  redis-server redis-6380.conf

• 验证

- 查看主节点信息   redis-cli -p 6379 info replication
   	role:master
   	connected_slaves:1
   	slave0:ip=127.0.0.1,port=6380,state=online,offset=1183,lag=0
   	master_replid:32125185597f85a2155d187ccd57168cf6681395
   	master_replid2:0000000000000000000000000000000000000000
   	master_repl_offset:1183
   	second_repl_offset:-1
   	repl_backlog_active:1
   	repl_backlog_size:1048576
   	repl_backlog_first_byte_offset:1
   	repl_backlog_histlen:1183
- 查看从节点信息
   	role:slave
   	master_host:127.0.0.1
   	master_port:6379
   	master_link_status:up
   	master_last_io_seconds_ago:0
   	master_sync_in_progress:0
   	slave_repl_offset:1239
   	slave_priority:100
   	slave_read_only:1
   	connected_slaves:0
   	master_replid:32125185597f85a2155d187ccd57168cf6681395
   	master_replid2:0000000000000000000000000000000000000000
   	master_repl_offset:1239
   	second_repl_offset:-1
   	repl_backlog_active:1
   	repl_backlog_size:1048576
   	repl_backlog_first_byte_offset:1
   	repl_backlog_histlen:1239
- 命令验证
   	./redis-cli -p 6379 set a aaa
   		OK
   	 ./redis-cli -p 6380 get a
   	 	"aaa"

哨兵模式

• 流程

1.多个sentinel发现并确认master有问题
2.选举出一个sentinel作为领导
3.选出一个slave作为master
4.通知其余slave成为新的master的slave
5.通知客户端主从变化
6.等待老的master复活成为新的master的slave

• 配置文件 sentinel.conf

port 26379
daemonize yes
# sentinel announce-ip <ip>
# sentinel announce-port <port>
dir /opt/redis-4.0.11/data
sentinel monitor mymaster 127.0.0.1 6379 2
# sentinel auth-pass <master-name> <password>
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000
# sentinel notification-script <master-name> <script-path>

• 配置文件说明

 - port :当前Sentinel服务运行的端口
 - dir : Sentinel服务运行时使用的临时文件 
3.sentinel monitor master001 192.168.110.10163792:Sentinel去监视一个名为master001的主redis实例，这个主实例的IP地址为本机地址192.168.110.101，端口号为6379，而将这个主实例判断为失效至少需要2个 Sentinel进程的同意，只要同意Sentinel的数量不达标，自动failover就不会执行
4.sentinel down-after-milliseconds master001 30000:指定了Sentinel认为Redis实例已经失效所需的毫秒数。当实例超过该时间没有返回PING，或者直接返回错误，那么Sentinel将这个实例标记为主观下线。只有一个 Sentinel进程将实例标记为主观下线并不一定会引起实例的自动故障迁移：只有在足够数量的Sentinel都将一个实例标记为主观下线之后，实例才会被标记为客观下线，这时自动故障迁移才会执行
5.sentinel parallel-syncs master001 1：指定了在执行故障转移时，最多可以有多少个从Redis实例在同步新的主实例，在从Redis实例较多的情况下这个数字越小，同步的时间越长，完成故障转移所需的时间就越长
6.sentinel failover-timeout master001 180000：如果在该时间（ms）内未能完成failover操作，则认为该failover失败
7.sentinel notification-script <master-name> <script-path>：指定sentinel检测到该监控的redis实例指向的实例异常时，调用的报警脚本。该配置项可选，但是很常用

• 三个定时任务

（1）每隔10s每个sentinel会对master节点和slave节点执行info命令作用就是发现slave节点，并且确认主从关系，因为redis-Sentinel节点启动的时候是知道master节点的，只是没有配置相应的slave节点的信息
（2）每隔两秒，sentinel都会通过master节点内部的channel来交换信息（基于发布订阅）
 作用是通过master节点的频道来交互每个Sentinel对master节点的判断信息
（3） 每隔一秒每个sentinel对其他的redis节点（master，slave，sentinel）执行ping操作，对于master来说若超过30s内没有回复，就对该master进行主观下线并询问其他的Sentinel节点是否可以客观下线

• 故障转移过程

1. 领导者选举
作用：选举出一个sentenel节点作为领导者去进行故障转移操作。
过程：
1). 每个做主观下线的sentinel节点向其他sentinel节点发送上面那条命令，要求将它设置为领导者。
2). 收到命令的sentinel节点如果还没有同意过其他的sentinel发送的命令（还未投过票），那么就会同意，否则拒绝。
3). 如果该sentinel节点发现自己的票数已经过半且达到了quorum的值，就会成为领导者。
4). 如果这个过程出现多个sentinel成为领导者，则会等待一段时间重新选举。

2. 选出新的master节点
redis sentinel会选一个合适的slave来升级为master，那么，如何选择一个合适的slave呢？顺序如下：
1). 选择slave-priority最高的slave节点（默认是相同）。
2). 选择复制偏移量最大的节点。
3). 如果以上两个条件都不满足，选runId最小的（启动最早的）。

3. 更改slave节点的master节点
当选举出新的master节点后，会将其余的节点变更为新的master节点的slave节点，如果原有的master节点重新上线，成为新的master节点的slave节点。

4. 通知客户端
当所有节点配置结束后，sentinel会通知客户端节点变更信息。

5. 客户端连接新的master节点
客户端收到节点信息后，会连接新的master节点。