那些让我印象深刻的bug--03

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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