Redis高可用梳理详解

为什么要有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高可用梳理详解的文章就介绍到这了,更多相关Redis高可用内容请搜索萤火虫技术以前的文章或继续浏览下面的相关文章希望大家以后多多支持萤火虫技术！