redis单点带来什么问题？

引言

相信大家面试有被问题过这样一个问题：你在工作过程中有遇到过什么生产问题？

每个人都会根据自己的经验和总结去回答，今天小面就和大家谈一谈redis单点的问题，处理思路，这样大家在面试的时候又多了一个能讲的案例，拿去和面试官吹逼不过分吧！废话不多说，我们开始今天的话题。

一、Redis单点会带来哪些问题？

1. redis单点发生故障，数据丢失，影响整体服务应用

在这个负载均衡、集群大规模应用的时候，当然也还有公司或者某些服务在使用一台redis作为缓存中间件或者数据库使用，小面有个朋友，他年前告诉我他们生产环境之前单机redis就缓存一些数据，后面在权限验证的处理中将认证token放在了redis中，某天redis所在服务器受到外部机房断电影响导致redis直接挂掉，其他的应用服务都是需要从redis中去获取token做验证的，因而其他关联的应用服务全部报错，不能使用，redis重启后有数据丢失，他们使用的是RDB存储策略，丢失了在上一次redis做刷写磁盘到断电前的数据，存储策略还有AOF，生产环境中一般是将RDB和AOF合并使用，不熟悉redis持久化的可以看之前的关于RDB和AOF的讲解。

redis单点.png

2. redis自身资源有限，无法承载更多资源分配

不知道你们有没有经历过单机版的redis在生产环境中跑起来，小面就有幸经历过一次。故事是这样的，在某年某月，我们项目上引入了redis做为缓存使用，而在一个版本开发中，有新的同事进来当时负责一个功能点的数据验证临时结果存储，这个数据校验结果有多大，从前端页面传的一个EXCEL表格，最大行是20000个，字段有20多个，后台解析关联的数据库表大概有4、5张，校验后的返回校验数据得有40多个字段吧，然后他把这个数据放到了redis中，测试时未进行压力测试，单个线程处理感觉不到redis有什么问题，到了上线的第二天，大量用户操作上传excel表格校验处理，后台处理的数据在redis中报增，

redis内存爆满.png

有两个错误异常出现，一个是在内存占满后，redis无法再保存新的数据，同时会启动内存清理策略，这个期间连接会有异常：

代码语言：shell复制

io.lettuce.core.RedisCommandTimeoutException: Command timed out after 3 second(s)

另一个是无法分配内存：

代码语言：shell复制

Redis Can’t save in background: fork: Cannot allocate memory

redis申请的主机内存已经是顶天了，我们排查发现就是内存不够了，这个很明显的问题就是redis自身资源有限，内存占用满了之后就无法使用了，这肯定是不允许的，一台redis已经解决不了这种对存储空间的需求问题了，所以我们采用了集群加分片的方式进行处理，这里不展开讲，后期会写一篇关于redis集群相关的文章，欢迎各位伙伴关注阅读。

上面这个实例只说明了redis资源受限的一个问题，redis资源受限不仅仅是存储空间上有限，计算机它的算力也是有限的，有更多算力需求来临时它也会支撑不住。

总结一句话就是计算机资源受限是因为存储上限和算力上限在无限增长的互联网需求资源的时候总会发生各种各样的问题，其解决思路就是不要把鸡蛋都放在一个篮子里。

3、并发访问，给服务器主机带来压力，性能瓶颈

并发访问压力2.png

大家应该都知道每一个和服务器建立的TCP连接都会消耗服务器资源，那么当大量的用户同一时刻访问同一台服务器，这是会有很多的tcp连接创建，势必就会给服务器带来巨大压力，神也抗住不，所以大家常常听到说要将产品做到高并发、高可用、高性能，这一个服务器访问压力问题存在就不能够支撑高并发。

二、redis单点存在的问题应该怎么解决？

从上述几点我们应该明确了服务器单点会存在着各种问题，那么前辈们为了解决单点服务器出现的问题，诞生了AKF拆分原则，AKF拆分原则同样可以运用到redis上，那么什么是AFK拆分原则，AFK原则用一简单的句话解释： 通过增加硬件机器来解决单机的容量和单点可用性的问题 。

它是基于X、Y、Z三个方向进行扩展，就是通过三个维度来扩容：

1. X轴是基于数据进行镜像复制的一个扩展方式，新增的机器和原有的机器拥有着同样的数据；
2. Y轴是基于数据分类代表着不同的功能，比如用户信息、操作记录、订单信息、商品信息等，新增的机器和原有的机器各自存放着人为划分的功能数据集；
3. Z轴是基于业务拆分的数据再进行拆分扩展，不同的数据落到不同的分区节点上。image.png

这三个拆分方向分别对应的解决了我们上边所说的单点带来的问题：

1. X轴解决了单点故障问题，每一台机器都有着相同的数据，其中一台挂掉马上切换到另一台；
2. Y轴解决了资源受限问题，按照功能划分的数据分拆到不同的机器上，减轻了每台机器的资源存储压力；
3. Z轴解决了访问压力问题，将业务数据再细分导向规则化的不同的机器，使得每台机器收到的并发访问压力就会大大减少。

三、总结

今天我们了解了redis单点存在的3个问题和AKF拆分原则理论，那么我们根据这个原则进行拆分扩容就可以使得redis单点问题得以解决，但这个AKF拆分原则也存在着一些问题，今天分享的知识就到这里结束了，咱们下期接着谈AKF存在的问题，欢迎持续关注！

云数据库Redis 数据库 sql 存储 压力测试

0 人点赞