使用redis可能出现的问题

[1] 缓存雪崩

指缓存由于某些原因（比如 宕机、cache服务挂了或者不响应）整体失效了，导致大量请求到达后端数据库，从而导致数据库崩溃，整个系统崩溃，发生灾难.

• 解决办法：可以给缓存设置不同的缓存时间，更新数据使用互斥锁或者通过双缓存在避免缓存雪崩.

[2] 缓存击穿

缓存击穿是指缓存中没有但数据库中有的数据.如果一些key被高并发访问**，恰好在这个时间点某个key缓存过期，从而导致了大量请求达到数据库**，，这就导致数据库中并发的去执行了很多不必要的查询操作，从而导致巨大冲击和压力.

• 解决办法：使用互斥锁，只让一个请求去load DB，成功之后重新写缓存，其余请求没有获取到互斥锁，可以尝试重新获取缓存中的数据.

[3] 缓存穿透

是指缓存和数据库中都没有的数据，而用户不断发起请求，导致请求都打到了数据库上，导致数据库异常.

• 解决办法：可以使用互斥锁或者无论是否取到结果都将结果存入缓存，还可以使用有效的机制（比如布隆过滤器）来拦截不合法的key值等.

[4] 三种问题区别记忆方法

在一个高频访问的应用系统中，每次用户的请求需要去DB中获取数据，会对数据库造成很大的压力、容易导致数据库的奔溃.所以才会出现缓存来分担一部分的数据库的压力. 但是使用缓存也带来了一系列问题:

打个比方，数据库是人，缓存是防弹衣，子弹是线程，本来防弹衣是防止子弹打到人身上的，但是当防弹衣里面没有防弹的物质时，子弹就会穿过它打到人身上.

1. 缓存雪崩（被霰弹枪打）："雪崩"对应的是大量请求，缓存某一时间失效了，然后大量请求到达后端数据库，从而导致数据库崩溃.

   解决方法：避免同时过期，构建多级缓存，部署多个redis实例。

2. 缓存击穿（被狙击枪多次打一点）："击穿"对应的是redis某点被（key）击穿。如果一些key被高并发访问，恰好在这个时间点某个key缓存过期，从而导致了大量请求达到数据库，，这就导致数据库中并发的去执行了很多不必要的查询操作，从而导致巨大冲击和压力.

   解决方法：加互斥锁，永不过期.

3. 缓存穿透（被巴雷特打）："穿透"最为严重，指的是缓存和数据库被穿透，都穿的透透的了。是指缓存和数据库中都没有的数据，而用户不断发起请求，导致请求都打到了数据库上，导致数据库异常.这时的用户很可能是攻击者.

   解决方法：缓存空值，布隆过滤器.

[5] 数据库和缓存的双写一致性问题

在高并发请求下很容易导致数据不一致的问题，如果你的业务需要保证数据的强一致性，那么建议不要使用缓存.在数据库中和缓存数据的删除或者写入过程中，如果有失败的情况，会导致数据的不一致.
解决办法：
双删延时的解决办法.可以先删除缓存数据，然后再更新数据库数据，最后再隔固定的时间再次删除缓存.
更新数据库产生的binlog订阅（使用canal）.将有变化的key记录下来，并且尝试去不断的去删除缓存（如果上次删除缓存失败）

缓存不一致详解：

最初级的缓存不一致问题及解决方案

问题：先修改数据库，再删除缓存.如果删除缓存失败了，那么会导致数据库中是新数据，缓存中是旧数据，数据就出现了不一致.

解决思路：先删除缓存，再修改数据库.如果数据库修改失败了，那么数据库中是旧数据，缓存中是空的，那么数据不会不一致.因为读的时候缓存没有，则读数据库中旧数据，然后更新到缓存中.

比较复杂的数据不一致问题分析

数据发生了变更，先删除了缓存，然后要去修改数据库，此时还没修改.一个请求过来，去读缓存，发现缓存空了，去查询数据库，查到了修改前的旧数据，放到了缓存中.随后数据变更的程序完成了数据库的修改.完了，数据库和缓存中的数据不一样了…

为什么上亿流量高并发场景下，缓存会出现这个问题？

只有在对一个数据在并发的进行读写的时候，才可能会出现这种问题.其实如果说你的并发量很低的话，特别是读并发很低，每天访问量就 1 万次，那么很少的情况下，会出现刚才描述的那种不一致的场景.但是问题是，如果每天的是上亿的流量，每秒并发读是几万，每秒只要有数据更新的请求，就可能会出现上述的数据库+缓存不一致的情况.

解决方案如下：

更新数据的时候，根据数据的唯一标识，将操作路由之后，发送到一个 jvm 内部队列中.读取数据的时候，如果发现数据不在缓存中，那么将重新读取数据+更新缓存的操作，根据唯一标识路由之后，也发送同一个 jvm 内部队列中.

一个队列对应一个工作线程，每个工作线程串行拿到对应的操作，然后一条一条的执行.这样的话，一个数据变更的操作，先删除缓存，然后再去更新数据库，但是还没完成更新.此时如果一个读请求过来，读到了空的缓存，那么可以先将缓存更新的请求发送到队列中，此时会在队列中积压，然后同步等待缓存更新完成.

这里有一个优化点，一个队列中，其实多个更新缓存请求串在一起是没意义的，因此可以做过滤，如果发现队列中已经有一个更新缓存的请求了，那么就不用再放个更新请求操作进去了，直接等待前面的更新操作请求完成即可.

待那个队列对应的工作线程完成了上一个操作的数据库的修改之后，才会去执行下一个操作，也就是缓存更新的操作，此时会从数据库中读取最新的值，然后写入缓存中.

如果请求还在等待时间范围内，不断轮询发现可以取到值了，那么就直接返回；如果请求等待的时间超过一定时长，那么这一次直接从数据库中读取当前的旧值.

高并发的场景下，该解决方案要注意的问题：

• 读请求长时阻塞

由于读请求进行了非常轻度的异步化，所以一定要注意读超时的问题，每个读请求必须在超时时间范围内返回.

该解决方案，最大的风险点在于说，可能数据更新很频繁，导致队列中积压了大量更新操作在里面，然后读请求会发生大量的超时，最后导致大量的请求直接走数据库.务必通过一些模拟真实的测试，看看更新数据的频率是怎样的.

另外一点，因为一个队列中，可能会积压针对多个数据项的更新操作，因此需要根据自己的业务情况进行测试，可能需要部署多个服务，每个服务分摊一些数据的更新操作.如果一个内存队列里居然会挤压 100 个商品的库存修改操作，每隔库存修改操作要耗费 10ms 去完成，那么最后一个商品的读请求，可能等待 10 * 100 = 1000ms = 1s 后，才能得到数据，这个时候就导致读请求的长时阻塞.

一定要做根据实际业务系统的运行情况，去进行一些压力测试，和模拟线上环境，去看看最繁忙的时候，内存队列可能会挤压多少更新操作，可能会导致最后一个更新操作对应的读请求，会 hang 多少时间，如果读请求在 200ms 返回，如果你计算过后，哪怕是最繁忙的时候，积压 10 个更新操作，最多等待 200ms，那还可以的.

如果一个内存队列中可能积压的更新操作特别多，那么你就要加机器，让每个机器上部署的服务实例处理更少的数据，那么每个内存队列中积压的更新操作就会越少.

其实根据之前的项目经验，一般来说，数据的写频率是很低的，因此实际上正常来说，在队列中积压的更新操作应该是很少的.像这种针对读高并发、读缓存架构的项目，一般来说写请求是非常少的，每秒的 QPS 能到几百就不错了.

我们来实际粗略测算一下.

如果一秒有 500 的写操作，如果分成 5 个时间片，每 200ms 就 100 个写操作，放到 20 个内存队列中，每个内存队列，可能就积压 5 个写操作.每个写操作性能测试后，一般是在 20ms 左右就完成，那么针对每个内存队列的数据的读请求，也就最多 hang 一会儿，200ms 以内肯定能返回了.

经过刚才简单的测算，我们知道，单机支撑的写 QPS 在几百是没问题的，如果写 QPS 扩大了 10 倍，那么就扩容机器，扩容 10 倍的机器，每个机器 20 个队列.

• 读请求并发量过高

这里还必须做好压力测试，确保恰巧碰上上述情况的时候，还有一个风险，就是突然间大量读请求会在几十毫秒的延时 hang 在服务上，看服务能不能扛的住，需要多少机器才能扛住最大的极限情况的峰值.

但是因为并不是所有的数据都在同一时间更新，缓存也不会同一时间失效，所以每次可能也就是少数数据的缓存失效了，然后那些数据对应的读请求过来，并发量应该也不会特别大.

• 多服务实例部署的请求路由

可能这个服务部署了多个实例，那么必须保证说，执行数据更新操作，以及执行缓存更新操作的请求，都通过 Nginx 服务器路由到相同的服务实例上.

比如说，对同一个商品的读写请求，全部路由到同一台机器上.可以自己去做服务间的按照某个请求参数的 hash 路由，也可以用 Nginx 的 hash 路由功能等等.

• 热点商品的路由问题，导致请求的倾斜

万一某个商品的读写请求特别高，全部打到相同的机器的相同的队列里面去了，可能会造成某台机器的压力过大.就是说，因为只有在商品数据更新的时候才会清空缓存，然后才会导致读写并发，所以其实要根据业务系统去看，如果更新频率不是太高的话，这个问题的影响并不是特别大，但是的确可能某些机器的负载会高一些.