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