当数据量变得庞大的时候，读写分离还是很有必要的。同时避免一个redis服务宕机，导致应用宕机的情况，我们启用sentinel(哨兵)服务，实现主从切换的功能。
https://www.cnblogs.com/jaycekon/p/6237562.html
一，主从分离（读写分离,主从复制）
首先我们默认已经安装了redis，然后复制master,slave1,slave2三个redis的文件。并把redis.conf拷贝到多个redis文件夹中来。不干扰原来的redis服务，我们master使用6000端口
配置方式一：
配置文件（redis.conf）
master配置修改端口
port 6000 requirepass 123456
info命令查看
role是不是master
slave1修改配置
port 6001 slaveof 127.0.0.1 6000 masterauth 123456 requirepass 123456
slave2修改配置：
port 6002 slaveof 127.0.0.1 6000 masterauth 123456 requirepass 123456
requirepass是认证密码，应该之后要作主从切换，所以建议所有的密码都一致， masterauth是从机对主机验证时，所需的密码。（即主机的requirepass）
启动主机：
redis-server redis.conf
启动从机：
redis-server redis1.conf
redis-server redis2.conf
配置方式二：在服务启动后配置
启动6001服务
进入客户端，查看当前服务器的状态并修改：
10.192.28.149:6001> slaveof 127.0.0.1 6000
检查
输入：
ps -ef |grep redis
可以看到主从机的redis已经相应启动。
我们来验证下 主从复制。
master: [root@localhost master]# redis-cli -p 6000 127.0.0.1:6000> auth 123456 OK 127.0.0.1:6000> set test chenqm OK slave1: [root@localhost slave2]# redis-cli -p 6001 127.0.0.1:6001> auth 123456 OK 127.0.0.1:6001> get test "chenqm" slave2: [root@localhost slave2]# redis-cli -p 6002 127.0.0.1:6002> auth 123456 OK 127.0.0.1:6002> get test "chenqm"
二，哨兵机制
2.1，哨兵机制的原理
主从复制可以把主节点的数据复制给从节点。从节点可以备份主节点的数据，起到主节点down调，顶上来接替主节点工作的作用。也可以起到分担主节点读压力的作用。
没有哨兵机制的时候，主从复制结构部署存在的问题是什么？也可以说redis主节点发生故障如何解决？
如果主节点down调，主从切换需要人工介入。
主从切换步骤为：
1、启用从节点为主节点。命令：slaveof no one
2、旧主节点的其他从节点变成新主节点的从节点。命令：slaveof new master
3、通知应用方redis主节点变成了新主节点。 修改客户端调用的地址并重启客户端。
4、旧主节点变成新主节点的从节点。 命令：slaveof new master
哨兵机制存在的意义：
为了实现redis故障转移的自动化。自动发现，自动转移。不需要人工参与。
哨兵机制是怎样的部署结构？
结合上图，主从复制节点是数据节点，哨兵机制部署的节点是监控节点，它们都是redis实例。但是哨兵节点不存储数据，它们监控主从数据节点的状态，若哨兵判定主节点down掉后，就会自动执行上边提到的手工操作的4步。
哨兵节点自动化完成故障转移的过程：
哨兵机制是怎样判断主节点down调的？
哨兵机制是建立了多个哨兵节点，它们共同监控数据节点的运行状况。同时哨兵节点之间也互相通信。交换对主从节点的监控状况。下面提到两个概念：
主观下线和客观下线：一个哨兵节点判定主节点down掉是主观下线。只有半数个哨兵节点都主观判定主节点down掉，此时多个哨兵节点交换主观判定结果，才会判定主节点客观下线。
基本上哪个哨兵节点最先判断出这个主节点客观下线，就会在各个哨兵节点中发起投票机制，每个哨兵都投自己为领导者。最终被投为领导者的哨兵节点完成主从自动化切换的过程。当判断为主观下线时，不会进行主从切换过程。
大家可能会好奇，如果master 重连之后，会不会抢回属于他的位置，答案是否定的，就比如你被一个小弟抢了你老大的位置，他肯给回你这个位置吗。因此当master 回来之后，他也只能当个小弟
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 的主观下线状态就会被移除。
期间我们还需要关注的一个问题：sentinel服务本身也不是万能的，也会宕机，所以我们还得部署sentinel集群，象我这样多启动几个sentinel。