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

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，限制一定时间内不能再访问。