万能的缓存

缓存能解决很多数据传输慢的问题。在互联网交互的时候，到处存在缓存。访问浏览器，

1、客户端chrome软件会将相关静态资源缓存到磁盘，下次访问的时候直接从磁盘加载。

2、服务器端nginx可以设置缓存，将常用的js/css/img等静态资源在第一次请求时候就压缩好，下次同样的请求来了直接访问。而不经过诸如cgi/apache后端模块处理。

3、cdn缓存，用户量上去了，或者说公司做大了必然遇到高成本带宽问题。那么通用的做法就是直接将静态资源存放到cdn，访问的时候，不经过业务服务器。这样就大大减少了流量需求。

4、redis内存高速缓存。上面提到的都是静态资源存放到磁盘，多次访问的时候直接返回结果。redis作为数据库数据中间件缓存，对一些常用的查询已经临时数据，存放到redis。下次需要的时候不直接从数据库中取，而是先命中redis在内存中是否存在，没有再到数据库中取。

万恶的缓存

这样看来经过这么多重缓存，用户体验那是相当的丝滑呀。但是对于出现问题的排错却让人手足无措。比如我最近就遇到几次关于缓存的无厘头排错体验：

1、阿里云全站cdn加速

既然服务器带宽有限，而这个博客网站更新的数据基本改变很少。所以就体验了一把全站cdn加速。

然而在某次博客代码版本更新后，发现总是不生效，甚至出现一些莫名其妙的问题。后来排查数据库问题，排查服务器配置，排查代码问题。。。哇，都没问题呀，最后过了一天，偶然才发现，我某某时间体验了一下cdn全站加速。。于是乎登录阿里云后台刷新一下缓存，果然就生效了。。。

于是乎，全站cdn加速就不再用了。。。

2、redis缓存排错

早上起来，本来想刷新一下redis缓存玩玩。结果就这一操作（当时操作没在意）。后台顿时无法访问了。。提示的错误竟然是https 302跳转。。。

于是我就跟着这个错误提示，排查了nginx配置很久。。。。重启了nginx几次。。。仍然不见效。

由于代码没有改动，所以又查看了一下数据库，对数据库进行1天，2天回滚。。问题依旧。

最后我才考虑到是redis的问题，果断把redis关掉，结果后台就可以访问了，于是乎肯定是redis缓存了https://协议，所以每次访问都重定向到https:// ，接下来在redis-cli命令行上刷新了缓存。这样就可以重新使用redis了。。。

总结

在排错的时候，往往会忽略缓存导致的问题。很多时候，排查了所有代码没问题，排查了数据库操作没问题，排查了服务器架构没问题。。。但是问题却依旧，于是乎就绝望了。殊不知，可能一个小小的缓存就能打败你强大的内心。哎，我已经被打败了好多次了。。