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

Posted 一个抓手

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了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也可以集群部署。

以上是关于Redis高可用架构设计以及常见问题分析的主要内容,如果未能解决你的问题,请参考以下文章

Redis:哨兵模式架构设计分析

分布式存储系统高可用架构设计分析

Redis的高并发持久化高可用架构设计

架构设计:系统存储(17)——Redis集群方案:高可用

Qunar Redis 高可用架构设计

Redis技术专题「高可用技术基础」一同分析一下Redis高可用的“基石”之主从架构的本质原理解析