Redis在数据缓存场景中的应用以及功能和性能测试注意事项

发布时间:2024年01月21日

1、思考

能不能将表中的数据全部都放到redis中缓存起来?有没有必要?能,但没有必要。

Redis是存在内存上的,造价比存在硬盘上要贵的多。如果这些数据用不到,没必要放到内存上去。

2、什么样的数据适合放到Redis中?

频繁读且少更新的热点数据,适合放在redis中。

开发同学会考虑,测试同学了解即可。

  • 频繁读的数据适合放在redis。例如热点数据,一段时间内,频繁的请求。
  • 频繁读取更新少的热点数据:适合
  • 频繁更新的热点数据:不适合
场景频繁不频繁
×
×-

3、Redis缓存的应用流程

在这里插入图片描述

4、什么情况下Redis会没有数据?

  • 第一次查询,数据需要从数据库查询再缓存起来
  • Redis数据过期,数据查询不到了,需要从数据库查询再缓存到Redis
  • Redis挂了,整个服务都访问不了,只能从数据库里面查询

5、功能测试中关注点

5.1 测试的目的

目的:帮开发检测到一些问题,使系统更加健壮。

5.1.1 不能直接修改数据库,而是通过app界面或API进行修改。

因为这个是带缓存的数据,优先从redis去拿,如果缓存存在,就不会读数据库了。

为什么通过api或者app去修改?
因为后端有一些业务逻辑处理等代码,这种方式更加安全,更正确。例如联系人头像是有缓存的,直接去数据库改了头像,发现app里并没有更新,需要再调用下updateProfile等相关api才能触发更新。

5.1.2 程序Bug

通过app界面或API修改了,但是拿到的还是老数据。这时候可能就是程序的bug,跟开发沟通是怎么做的。

有一些业务场景,允许在一段时间拿到老数据。使用redis抗住高并发,带来高性能,就是允许在一定时间内拿到的数据是旧的,但过了过期时间一定能拿到最新的。

例如一些营销广告等,1s和5min去访问一次,性能差别很大,所以为了提高性能,允许在一段时间拿到老数据。

5.1.3 允许的到期时间

有时候拿到老数据不一定就是不正确,是否允许业务场景

5.2 数据不一致的问题

图1:主动更新
在这里插入图片描述图2:Redis在互联网系统中的应用流程
在这里插入图片描述

5.2.1 数据更新策略是什么?主动更新还是被动更新?

  • 主动更新:在业务逻辑当中,当客户端有更新操作时,更新数据库的同时,也更新redis缓存。

  • 被动更新【高并发场景推荐】:在业务逻辑中,不更新redis缓存,删除redis缓存,通过查询的时候,获取最新的数据库值。(图2:查redis的时候无数据,会去查询数据库,将数据库返回的结果,一份给到redis,一份返回客户端,这就是被动更新)

  • 异步更新:第3方插件等,例如触发器,开发同学更熟悉,测试同学主要了解主动和被动更新即可。

5.2.2 如何保持数据一致性?

作为测试同学,不用去深入,但是要求数据一致性保证到什么程度,了解原理即可。根据实际业务场景需要来测试。

5.2.3 涉及到的具体业务数据是什么?做针对性的测试

具体业务具体分析。

  • 例如1:业务允许一段时间内数据不一致。5分钟缓存内,无论做多少修改,都不会影响效果。但测试时,5分钟内做了多次修改,每次都能拿到最新的,那肯定不对

  • 例如2:业务要求实时性,但是过期时间内,多次更新数据,都拿不到最新结果,这肯定也不对。

5.3 Redis数据过期

5.3.1 数据是否需要设置过期时间?

不设置也是可以的,根据业务需要来定

5.3.2 过期时间设置多少比较合适?

过期时间:TTL,默认值是-1,永久有效

当键值对的 TTL 过期后,Redis 会自动删除该键值对。TTL过短或者过长都不利于Redis的性能和稳定性,应该合理设置 TTL。

  • 如果 TTL 设置过短,会导致 Redis 中的数据频繁过期,从而增加 Redis 的负担;如果 TTL 设置过长,会导致 Redis 中存储的数据越来越多,从而影响 Redis 的性能和稳定性。

  • 以下是 Redis TTL 的合理设置建议:

  • 根据业务需求设置 TTL。不同的业务需求对键值对的存储时间有不同的要求,例如,对于一些频繁更新的数据,可以设置较短的 TTL,而对于一些不经常更新的数据,可以设置较长的 TTL。

  • 避免设置过长的 TTL。如果设置过长的 TTL,会导致 Redis 中存储的数据越来越多,从而影响 Redis 的性能和稳定性。通常建议将 TTL 设置为几分钟到几小时之间。

  • 使用 Redis 的过期键通知机制。Redis 提供了过期键通知机制,可以在键值对过期时通知应用程序。通过使用该机制,应用程序可以及时清理过期的数据,从而避免 Redis 中存储的数据越来越多,影响 Redis 的性能和稳定性。

5.3.3 设置了过期时间,数据过期是否会正常删除?

例如,开发同学把过期时间的单位,毫秒和秒搞错了。因此过期时间也是一个很重要的测试点。

5.4 其他问题:

5.4.1 Redis曾经暴露过安全问题

要求开发设置密码连接redis

5.4.2 Redis连接是否存在超时?访问是否存在延时?

连接变慢,超时了,超时的原因是什么?是不是redis的用法存在问题。

例如zset数据类型,里面数据量达到百万、千万差别,某些join操作等等,异常的缓慢。

5.4.3 是否开启了持久化?持久化策略是什么?是否合适?以及redis重启的时候,采用什么样的预热方式比较好?

开发同学可能会使用rdb和aof相结合。预热:如果内存数据超过3~4GB,加载硬盘上的持久化数据就会比较长。通常2个G是比较快的。

6、性能测试

6.1 缓存击穿

在缓存过期的一瞬间,同时有大量的请求打进来,由于此时缓存过期了,所以请求最终都会走到数据库,造成瞬时数据库请求量大、压力骤增,甚至可能打垮数据库

6.2 缓存失效的两种情况

1、高峰期大面积缓存Key失效(所有请求全部访问后端数据库)
2、局部高峰期,热点缓存Key失效(导致海量的请求直击数据库)

缓存数据有效期到来的那一瞬间,例如:

  • 突发重要热点事件
  • 春节发红包
  • 电商降价、抢购、促销活动

6.3 缓存穿透

访问一个缓存和数据库都不存在的key,此时会直接打到数据库上,并且查不到数据,没法写缓存,所以下一次同样打到数据库上。

缓存起不到作用,请求每次都会走到数据库,流量大时数据库可能会被打挂。此时缓存就好像被“穿透”了一样,起不到任何作用。

例如:黑客大量的恶意请求,redis都兜住了,那什么情况下,redis兜不住呢?
例如当前数据库中的订单号最大是100,黑客传一个1000或者10000的,查询数据库时,数据库没有,redis也没有。这种大量的恶意请求,会造成缓存穿透。

6.4 如何测试验证

使用loadbalancer、Jmeter、AB等压测工具进行模拟测试。例如在缓存过期时,大量并发请求。

6.5 缓存雪崩

缓存雪崩是指缓存失效后导致服务大面积崩塌的后果,犹如高山的雪崩。

6.5.1 缓存雪崩的原因

缓存失效:缓存击穿、缓存穿透、缓存服务不可用(挂掉)

6.5.2 缓存雪崩风险

缓存雪崩:因为缓存服务挂掉或者热点缓存失效,从而导致海量请求去查询数据库,导致数据库连接不够用或者数据库处理不过来,从而导致整个系统不可用。

数据库服务器压力大,依赖数据库的其他系统也会面临崩溃风险。
例如:公司往往不止一个应用程序,并且后端服务之间相互有依赖。当某个应用程序依赖的数据库或者下游系统不堪重负,那其他兄弟程序、其他应用等也会受到严重影响,最终所有的服务都会瘫痪。

6.6 解决方案

6.6.1 缓存击穿

  • 过期时间打散:针对高峰期大面积Key失效
  • 热点数据不过期:针对单个热点数据,把过期时间拉长或者不过期
  • 互斥锁:万一实在是拿不到缓存,通过并发控制:互斥锁、分布式锁、JVM锁等,将请求控制在下游服务器能够承受的范围就可以。例如:将一部分请求直击数据库,另外一部分请求访问redis,等访问数据库的流量好了有缓存了,其他请求只用读redis缓存就行了。
  • 缓存降级:Redis服务挂了,缓存备用,数据兜底,做服务降级、redis降级。

6.6.2 缓存穿透

  • 业务规则校验:日期范围(请求超过了当前时间)、数据范围业务规则的校验,不符合直接返回。
  • 数据格式校验:例如,特意设计ID,前16位表示时间,中间3位表示业务分类代码,后面3位表示随机数等等。
  • 布隆过滤器:把海量的请求参数的真实值,压缩放到一个过滤器里。每次请求的时候通过过滤器进行验证,如果是真实的就通过验证,如果不真实就忽略。布隆过滤器可以通过Redis来实现。
  • IP黑白名单限流:禁止访问,例如:发现恶意请求的IP,限制一定时间内不能再访问。
文章来源:https://blog.csdn.net/weixin_44691253/article/details/135717268
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。