为什么要有Redis高可用？
痛点：
- 如果一个服务的redis，只有一个master节点，那哪天接口机跟redis机器网络不通，或者redis机器故障了，不就访问不了Redis了，如果服务强依赖redis，那不就崩了
- master多节点级别的高可用：如果redis有master节点，以及还有slave节点，那如果网络不通、redis机器故障了，哪怕故障1个小时，整个服务的redis都受影响，那如果redis有多个master节点（4个），数据分片到这些master里面，那redis机器如果只是挂了一个机器，受影响也是1/4的数据。损失减少3/4
- 地区级别的redis高可用：如果服务是南北都有部署的，广州访问广州地区的redis，北京访问北京的redis。如果北京地区redis挂了，可以北京地区连广州redis，或者直接北京请求转发到广州；或者客户端收到北京失败请求后，重试到广州
高可用的手段
高可用的本质是有备份，在出现故障的时候，有backup可以提供服务。 所以问题核心是备份，那么怎么备份呢？
一下按几个层次来简单解析一下：
持久化：
解决的痛点：数据落盘，不会因为redis挂了内存数据都丢了
redis数据存在内存的，如果redis挂了，那么重启后内存数据就丢失，没有备份。此时就是需要持久化了，即把redis存入的数据，同时也写一份到磁盘，在redis挂了重启的时候，可以重新导入磁盘数据，来达到恢复的目的。
好处：
- 有了磁盘的备份，故障的时候，可以通过磁盘数据恢复
坏处：
- 依然是单点服务，数据恢复的时候需要时间，这个时间长短要看数据大小而定，恢复过程中，服务依然是不可用
- 非自动化，要手动恢复
主从同步
解决的痛点：多节点备份数据
上面说的持久化，痛点是在故障的时候，还得手动通过磁盘文件恢复。 那么主从同步可以解决这个痛点 具体是这么做的：redis主节点，挂N个从节点，slave节点实时同步master节点的数据，在master挂了的时候，可以立刻把slave提升成为master节点。 因为slave有了master的所有数据，因此可以直接切换，不用从磁盘恢复数据，大大缩短这个恢复时间。
好处：
- 故障时候，不用从磁盘恢复数据，减短故障时间
- slave节点一直保持同步，所以数据是最新的，可以直接提升为master
- 读写分离，master接收写请求，slave接收读请求。
坏处：
- 如果代码写死了链接master节点，此时切换了slave节点，代码就要更改redis连接配置。解决方案：因此需要设置一个VIP，中间件IP，客户端连接这个VIP即可，VIP后面怎么转发，对代码透明。
- 非自动切换，需要手动切换，深夜时间无人值班，没发现即时会让故障时间延长。
哨兵模式（Sentinel）
解决的痛点：自动故障转移
出故障的时候可能夜晚，又必须要精通的运维才能快速搞定，否则一定崩了，影响服务和用户。 有了主从同步，数据得以备份，以备故障的时候可以容器。但是这个故障切换要手动操作，哨兵模式就是解决这个痛点：自动转移故障
工作原理： sentinel哨兵也是一个集群，而且是独立于redis集群的一个服务。 因此哨兵是多个节点的，他的本质原理就是，每个哨兵每秒定时发送ping给master，等master回应 如果回应正常，那没问题 如果回应超时，那就需要关注。但是超时也有可能很多原因，比如网络不通畅、偶发的丢包等等。 假设有3个哨兵： 如果只有一个哨兵得不到回应，他会标识master 主观下线，即只是他自己认为master下线了 但另外两个哨兵是正常的，那就说明master没有真的下线，可能只是哨兵1网络问题
这样就有个好处，必须要多数哨兵认为master下线了，才会切换主从。 哨兵自己认为master挂了，这种叫主观下线 半数以上哨兵认为master挂了，他们通过互相信息同步，就认为master是客观下线 这个时候，就需要走主从切换流程了
主从切换原理： 正常情况下，多个slave配置，都配置了slaveof master 如果master被哨兵认为客观下线了，此时就要进行一次“投票”，从slave里面选出新的master。 具体就是修改配置文件、重启服务，这几个操作的自动化
简化理解 其实就好比平常工作中，写了个脚本，定时扫描漏单之类的，这个定时脚本也要高可用，所以就部署在多个接口机上。 然后脚本定时探测一下master是否正常，多数发现不正常了，就触发自动更换配置文件，reload服务。 就是这么个道理
标识下线机制，这个类似rpc重试机制，一个机器返回5xx，得重试到另外一个机器，都失败了，才返回5xx给客户端。
问题： 问题1. 如果代码写死链接的masterip， 这样切换了，代码还得发版上线才能生效，所以代码不能这么说傻叉写死一个IP。
解决方案：需要有一个类似中间件的组件，来做这个事。比如mysql就有个中间件，端口就是127.0.0.1:9981服务，后面转发到redis真实IP 。当然故障切换后，这个中间件得知道master是谁了。这个也是可以通过下发配置通知的？
问题：还是客户端直接访问的sentinel ? sentinel担任起中间件的角色？因为它知道master和slave具体信息
实际解决方案：就是客户端连接3个哨兵的ip:端口，让哨兵来返回redis的主从节点，他也帮你连接好了，返回一个redis实例给你，所以相当于是哨兵是中间件，客户端（代码）先连接到哨兵，哨兵返回master，再帮你哦链接后redis，返回给你。 这样就不用怕主从切换后的IP变更了
结构图：
Redis Cluster 集群方案
哨兵机制解决的是主从自动切换的痛点。 另外一个痛点是：redis单机存储有限；数据单点 场景，比如专辑业务的痛点：
- redis数据都是几十G的，如果只有一个master节点，那么这个redis机器要很大内存，这样的配置很贵
- 同时，如果真有这么大内存的redis机器，那么全部数据都单点存储，一旦这个机器挂了，就影响全部用户
Redis Cluster就是解决以上两个痛点的解决方案：
- 数据分片，key按规则hash到不同的节点，就算某些节点挂了，之影响那个节点的数据，提高高可用性
- 每个机器的内存都不用太大，甚至集齐N个4G内存的机器，都能组成一个大容量集群
问题： Redis Cluster如何解决故障自动转移？ 如何分片，分片规则是怎样的？ 用了Redis Cluster集群，还需要哨兵做主从切换吗？ 你的业务redis集群的架构是怎样的？（字节面试题）