redis cache的使用大大提高了APP应用程序的性能和效率，特别是在数据查询方面。 但同时也带来了一些问题。 其中，最重要的问题是数据完整性问题，从严格意义上讲，这个问题是解决不了的。 如果对数据完整性的要求较高，则缓存不可用。
其他一些典型问题是缓存直通、缓存雪崩和缓存破坏。 目前，业界也有比较受欢迎的解决方案。 本文既不是更完美地解决这三个问题，也不是颠覆业界流行的解决方案。 相反，从实际的代码操作中显示这三个问题现象。 之所以这么说，是因为光看这些问题的学术解释，脑子里有难以想象的概念，有了实际的代码演示，就能加深对这些问题的理解和认识。
缓存穿透
缓存直通是查询单个数据库中不存在的数据。 正常的缓存使用过程通常是：数据查询首先进行缓存查询，如果key不存在或key过期，则查询数据库，并将查询的对象放入缓存中。 如果数据库查询对象为空，则无法将其放入缓存中。
Redis缓存进程
代码流程
参数化对象如果基于主键idkey从缓存检索对象的对象不为空，直接返回的对象为空，或者从进行数据库查询的数据库查询检索的对象不为空，则将其放入缓存如果传递的参数为-1，会怎么样？ 此-1是不存在的对象。 每次都去查询数据库，但每次查询都是空的，每次都不缓存。 如果存在恶意攻击，则可以利用此漏洞对数据库施加压力或破坏数据库。 即使采用UUID，也很容易找到不存在的密钥进行攻击。
小编在工作中，采用缓存空值的方式。 也就是说，在【代码流】的第5步中，如果数据库中的查询对象为null，则也包含缓存。 但是，所设置的缓存的过期时间较短，例如，设置为60秒。
高速缓存空值
缓存雪崩
高速缓存雪崩是指在某个时间段高速缓存集中到期。
雪崩发生的原因之一，比如写本文的时候，很快就会达到双十二零时，很快就会迎来抢购。 这个商品是时间集中放在现金里的。 假设有一个小时的高速缓存。 那么到凌晨一点，这些商品的现金都将过期。 访问这些商品的查询全部落入数据库，对数据库来说会产生周期性的压力峰值。
在进行电子商务项目时，一般采用不同的分类商品，缓存不同的周期。 在同一分类的商品中，添加随机因子。 这样可以尽可能分散缓存过期时间，而且热门类别的商品缓存时间长，热门类别的商品缓存时间短，还可以节约缓存服务的资源。
缓存时间加入suijiyinzi
其实集中期限过期并不是很致命。 相对致命的缓存雪崩是缓存服务器所在的节点瘫痪或网络断开。 自然形成的缓存雪崩，一定会在一个时间段集中创建缓存，所以那时数据库可以承受压力，那时数据库也可以承受压力。 它只会给数据库带来周期性的压力。 缓存服务节点的停机时间无法预测对数据库服务的压力，很可能会导致数据库立即崩溃。
缓存击穿
现金细分是指密钥是一个非常热点，承担着大的合并，大的合并集中访问这一点。 在这个密钥失效的瞬间，持续的大合并突破缓存，直接向数据库提出请求，就像在屏障上打洞一样。
做电子商务项目时，把这个商品“爆买”。
其实，在很多情况下，这样的爆款很难给数据库服务器带来巨大的压力。 没有几家公司达到这个水平。 所以，实务主义编辑对主要商品早做准备，以免现金失效。 即使一部分商品自己发酵成了炸药，也只要不要就这样过期就可以了。
从大街到简，mutex key互斥锁真的不能用。
结束语
流行问题面前一定有流行的解决办法，但有时也要根据自己的实际情况适当应对。 大胆设计，你的解决方案可能会流行。