Redis高可用架构设计以及常见问题分析

Redis的使用非常简单，只需要安装配置一下就能轻松上线，短时间不会出现什么问题，但是随着时间推移，Redis实例增多，客户端调用繁杂，真正的问题开始出现，整个关系就变得非常乱。Redis从使用角度来讲是需要像应用服务一样去治理的。

下面先看一段日常开发过程中常见的对话：

开发：Redis为啥不能访问了?
运维：刚刚服务器内存坏了，服务器自动重启了。

开发：为什么Redis延迟这么久?
运维：大哥，不要在Zset里面放几万条数据，插入排序的后果很严重啊!

开发：写进去的key呢，为什么不见了?
运维：你的Redis内存超过最大大小了，不常用的key都丢了呀!

开发：刚刚为啥读取全部失败了?
运维：刚刚网络临时中断了一下，slave全同步了，在全同步完成之前，slave的读取全部失败。

开发：我刚刚想到一个好方案，我需要800GB的Redis，什么时候能准备好呢?
运维：大哥，我们线上的服务器最大也就256GB，别玩这么大好吗?

一些常见策略以及其弊端：

1.单机不是不安全吗?那么就开启主从+Keepalived，用虚IP地址在master和 slave两边漂移,master挂了直接切换到slave。

主从+Keepalived 的方案，本来是个很好的方案，但是忽略了主数据节点挂掉的情况。Redis的单进程、单线程设计是其简单和稳定的基石，只要不是服务器发生了故障，在一般情况下是不会挂的。但同时，单进程、单线程的设计会导致Redis接收到复杂指令时会忙于计算而停止响应，可能就因为一个Zset或者keys之类的指令，Redis计算时间稍长，Keepalived就认为其停止了响应，直接更改虚IP的指向，然后做一次主从切换。过不了多久，Zset和 keys之类的指令又会从客户端发送过来，于是从机上又开始堵塞，Keepalived就一直在主从机之间不断地切换IP。终于主节点和从节点都堵了，Keepalived发现后，居然直接将虚IP释放了，然后所有的客户端都无法连接Redis了，只能等运维到线上手工绑定才行。

2.数据放内存不是不安全吗?可以开启数据落盘，根据业务需要决定落盘规则，有AOF的，也有RDB的。

数据落盘也引起了很大的问题，RDB属于非阻塞式的持久化，它会创建一个子进程来专门把内存中的数据写入RDB文件里，同时主进程可以处理来自客户端的命令请求。但子进程内的数据相当于是父进程的一个拷贝，这相当于两个相同大小的Redis进程在系统上运行，会造成内存使用率的大幅增加。如果在服务器内存本身就比较紧张的情况下再进行RDB配置，内存占用率就会很容易达到100%，继而开启虚拟内存和进行磁盘交换，然后整个Redis的服务性能就直线下降了。

另外，Zset、发布订阅、消息队列、Redis的各种功能不断被介绍，开发者们也在利用这些特性，开发各种应用，但从来没想过这么一个小小的Redis 有这么多新奇的功能，它的缺点在什么地方，什么样的场景是不合适用的?这时Redis在大部分的开发者手上就是像是一把锤子，看什么都是钉子，随时都一锤了事。同时也会渐渐地淡忘了开发的一些细节点和规范，因为用它解决性能的问题是那么轻松简单，于是一些基于Redis的新奇功能就接连不断地出现了:基于Redis的分布式锁、日志系统、消息队列、数据清洗，等等，各种各样的功能不断上线使用，从而引发了各种各样的问题。这时候原来那个救火神器就会变成四处点火的神器，Redis堵塞、网卡打爆、连接数爆表等问题层出不穷，经过这么多折腾，Redis终于也变成了大家的噩梦了。

总结以下几点需要解决：

1. 必须搭建完善的监控系统，在这之前要先预警，不能等到发生了，我们才发现问题。
2. 控制和引导Redis 的使用，我们需要有自己研发的Redis客户端，在使用时就开始控制和引导。
3. Redis的部分角色要改，将Redis 由 storage角色降低为cache角色
4. Redis的持久化方案要重新做，需要自己研发一个基于Redis协议的持久化方案，让使用者可以把 Redis当DB用。
5. Redis 的高可用要按照场景分开，根据不同的场景决定采用不同的高可用方案。

具体方案：

1. 重建Redis客户端，在客户端内植入日志，记录所有操作事件，如：耗时、key、value大小、网络断开等，由一个收集程序进行分析和处理。
2. 设置阈值报警，通知到运维系统，运维系统基于运维数据来自动故障转移、扩容、分片、负载均衡等。
3. 取消直接的IP端口连接方式，通过配置中心分配IP端口，当Redis发生问题需要切换时可直接在配置中心修改，由配置中心推送新的配置到客户端。
4. 解决研发人员使用Redis规范问题，将Redis的命令操作分为安全命令和不安全命令，安全命令可直接使用，不安全命令需要分析审核后才能打开，也由配置中心控制。
5. 将Redis定位成缓存角色，不做其他用途。
6. Redis采用主从+哨兵的模式部署，通过一致性Hash算法均衡分片。
7. 做一个Redis的Proxy，提供统一的入口点，Proxy也可以集群部署。