随着近期发布的一篇文章印象深刻的bug,也被小伙伴问到之前写过的一篇文章中的印象深刻的bug没看的太明白,今天再回过头来重新解答一下,原文如下:那些让我印象深刻的bug--01

之前的文章在描述的是一个由于开发缓存的key设置的不合理导致的缺陷,今天还是围绕这个现象来展开描述。

先来看一下为什么要加缓存?

比如我们访问一个网站的时候,页面是不是经常会去加载一些图片以及js之类的静态文件,访问网站到加载完的这个过程中耗时可能比较长,对用户的体验不太好,如果每次都要这么长的时间,那久而久之用户是不是就会失去耐心呢,因此,浏览器一般会将这种访问过的静态资源缓存起来,下次再需要加载的时候,就直接从缓存中去取,这样会提高页面渲染的速度。

同理,相同的一个接口,如果同样的查询条件,返回的都是同样的数据,那为什么在一个比较短的时间内,每次都要从数据库去查数据呢?为了减轻数据库的压力,也为了提高接口的性能,针对一些访问量比较大并且数据变化比较小的数据,接口会将查询结果缓存起来。其中一种可选的方案就是将结果缓存到redis中。

接口加了缓存之后,测试的时候有什么要注意的?

接口加缓存之后,会有什么显著的效果呢?比如原来一个接口查询需要1分钟才能返回结果,那么第二次用相同的条件查询的时候,可能就只需要1秒不到了。看上去缓存很方便,但是使用不当的话,容易造成重大的问题。

1、测试人员在测试接口的时候,要跟开发确认一下接口是否有缓存,缓存失效/刷新的时间是多长,以及缓存是以哪几个关键字段去设置唯一key的。尤其要检查这个唯一的key设置的规则是否合理 ,一般相同的条件会命中缓存,但如果设置错误,就会返回错误的数据。

2、做压测的时候,要确认下缓存的开关是否关闭

3、测试人员要了解缓存的设计和实现的大致细节,便于更好的测试这块相关的业务是否均合理,返回的数据是否正确

举例说明缓存的key设置不合理可能会出现的bug

假设现在有一个查询部门每个月使用的成本的接口,入参的话要传入token以及部门id进行查询。

那如果在这个接口上加上缓存,并且设置部门id是缓存的key,理论上不同的用户去查询相同的部门id的数据时,应该返回相同的数据。

但是,实际上,可能业务场景并不是你想的这样,假设你和你的上级领导都要查本部门的成本数据,你觉得你看到的数据和你上级看到的数据会一样吗?有可能接口层面还会有数据权限的概念,也就是说,你看到的数据和你领导看到的数据可能不一样,领导看到的是整个部门所有员工的数据汇总,而你作为下属只能看到自己的数据,因此,像这种接口的话 ,最起码设置key的时候,可能还得把userid加进去了。

看到这,当面试官下次问你缓存相关的问题或者问你有没有什么印象深刻的bug时,你的心中有思路了吗?

Logo

华为云1024程序员节送福利,参与活动赢单人4000元礼包,更有热门技术干货免费学习

更多推荐