能不能将表中的数据全部都放到redis中缓存起来?有没有必要?能,但没有必要。
Redis是存在内存上的,造价比存在硬盘上要贵的多。如果这些数据用不到,没必要放到内存上去。
频繁读且少更新的热点数据,适合放在redis中。
开发同学会考虑,测试同学了解即可。
场景 | 频繁 | 不频繁 |
---|---|---|
读 | √ | × |
写 | × | - |
目的:帮开发检测到一些问题,使系统更加健壮。
因为这个是带缓存的数据,优先从redis去拿,如果缓存存在,就不会读数据库了。
为什么通过api或者app去修改?
因为后端有一些业务逻辑处理等代码,这种方式更加安全,更正确。例如联系人头像是有缓存的,直接去数据库改了头像,发现app里并没有更新,需要再调用下updateProfile等相关api才能触发更新。
通过app界面或API修改了,但是拿到的还是老数据。这时候可能就是程序的bug,跟开发沟通是怎么做的。
有一些业务场景,允许在一段时间拿到老数据。使用redis抗住高并发,带来高性能,就是允许在一定时间内拿到的数据是旧的,但过了过期时间一定能拿到最新的。
例如一些营销广告等,1s和5min去访问一次,性能差别很大,所以为了提高性能,允许在一段时间拿到老数据。
有时候拿到老数据不一定就是不正确,是否允许业务场景
主动更新:在业务逻辑当中,当客户端有更新操作时,更新数据库的同时,也更新redis缓存。
被动更新【高并发场景推荐】:在业务逻辑中,不更新redis缓存,删除redis缓存,通过查询的时候,获取最新的数据库值。(图2:查redis的时候无数据,会去查询数据库,将数据库返回的结果,一份给到redis,一份返回客户端,这就是被动更新)
异步更新:第3方插件等,例如触发器,开发同学更熟悉,测试同学主要了解主动和被动更新即可。
作为测试同学,不用去深入,但是要求数据一致性保证到什么程度,了解原理即可。根据实际业务场景需要来测试。
具体业务具体分析。
例如1:业务允许一段时间内数据不一致。5分钟缓存内,无论做多少修改,都不会影响效果。但测试时,5分钟内做了多次修改,每次都能拿到最新的,那肯定不对
例如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 的性能和稳定性。
例如,开发同学把过期时间的单位,毫秒和秒搞错了。因此过期时间也是一个很重要的测试点。
要求开发设置密码连接redis
连接变慢,超时了,超时的原因是什么?是不是redis的用法存在问题。
例如zset数据类型,里面数据量达到百万、千万差别,某些join操作等等,异常的缓慢。
开发同学可能会使用rdb和aof相结合。预热:如果内存数据超过3~4GB,加载硬盘上的持久化数据就会比较长。通常2个G是比较快的。
在缓存过期的一瞬间,同时有大量的请求打进来,由于此时缓存过期了,所以请求最终都会走到数据库,造成瞬时数据库请求量大、压力骤增,甚至可能打垮数据库
1、高峰期大面积缓存Key失效(所有请求全部访问后端数据库)
2、局部高峰期,热点缓存Key失效(导致海量的请求直击数据库)
缓存数据有效期到来的那一瞬间,例如:
访问一个缓存和数据库都不存在的key,此时会直接打到数据库上,并且查不到数据,没法写缓存,所以下一次同样打到数据库上。
缓存起不到作用,请求每次都会走到数据库,流量大时数据库可能会被打挂。此时缓存就好像被“穿透”了一样,起不到任何作用。
例如:黑客大量的恶意请求,redis都兜住了,那什么情况下,redis兜不住呢?
例如当前数据库中的订单号最大是100,黑客传一个1000或者10000的,查询数据库时,数据库没有,redis也没有。这种大量的恶意请求,会造成缓存穿透。
使用loadbalancer、Jmeter、AB等压测工具进行模拟测试。例如在缓存过期时,大量并发请求。
缓存雪崩是指缓存失效后导致服务大面积崩塌的后果,犹如高山的雪崩。
缓存失效:缓存击穿、缓存穿透、缓存服务不可用(挂掉)
缓存雪崩:因为缓存服务挂掉或者热点缓存失效,从而导致海量请求去查询数据库,导致数据库连接不够用或者数据库处理不过来,从而导致整个系统不可用。
数据库服务器压力大,依赖数据库的其他系统也会面临崩溃风险。
例如:公司往往不止一个应用程序,并且后端服务之间相互有依赖。当某个应用程序依赖的数据库或者下游系统不堪重负,那其他兄弟程序、其他应用等也会受到严重影响,最终所有的服务都会瘫痪。