redis使用中的四大问题

一、数据不一致(保持数据的最终一致性)

定义：主要就是指缓存中的数据和数据库中的数据不一致情况。

产生的原因：

当有数据修改时，无论是先修改数据库的值，还是先修改缓存中的值，都会发生数据不一致的情况，更好的解决方式，就是先更新数据库的值，在进行删除操作，但是这样的操作也会造成数据的不一致问题。主要是在两个方面，一个就是不能保证操作的原则性时，可能出现缓存不一致的情况，另一种就是在并发场景下，出现缓存不一致。

原子性问题：

先删除缓存，再更新数据库：当我们的删除缓存成功后，这时写入数据库失败，当我们再来请求这个数据时，首先从缓存中没有拿到值，去数据库读取，那么读取到的是旧值，存在问题。

先更新数据库，再删除缓存：当更新数据库成功后，删除缓存失败时，应用再去读取数据时，缓存命中，直接读取缓存的值为旧值，数据不一致。

解决思路：

重试机制：可以将修改的数据放入到消息中间件中(如Kafka)，当我们操作redis失败，或者修改数据库失败时，可以再次从消息中间件中拿出数据，进行再次操作。

并发下的问题：

比如A线程首先去修改了数据，将2->1;先将缓存中的数据删除，然后去修改数据库(但是因为网络延迟比较慢)，此时B线程来读取数据，发现缓存中没有数据，去读数据库(读到的是旧值)，这是将数据2写入缓存，这个时候A线程恢复了工作，将数据的值改为了1，那后续的操作走缓存就只能拿到旧值2，出现了缓存不一致。

解决思路：

延迟双删：也就是在A线程更新完数据库之后，sleep一段时间，再次将缓存中的数据进行删除，这样后续的读取操作就是从数据库中读取到新值，回写给缓存；那么这个sleep的值应该设置为多少呢？就需要根据时间情况来定，一般就是稍大于B线程的操作时间。

终极解决思路：通过mysql的binlog日志，进行异步同步，比如阿里开源的Canal，就是通过binlog去异步更新缓存数据，其流程如下：

二、缓存雪崩

定义：缓存雪崩是指大量的数据在redis缓存中没有数据，导致请求打到数据库层，导致数据库请求压力大增。

产生原因：

缓存中的数据，在某一个时候，数据大量过期

.缓存系统导致出现宕机。

解决思路：

针对数据的key，设置随机的过期时间，保证在某一时刻，不会存在大量的缓存失效。

服务降级方案：针对非核心数据，暂停从缓存中读取数据，直接返回空值，或者错误信息

三、缓存击穿

定义：缓存击穿是指，某些热点数据，在缓存中无法命中，导致大量请求打到数据库服务器，导致数据库压力大增，影响性能。

产生原因：热点数据过期导致。

解决思路：

对于热点数据不设置过期时间，保证能够缓冲命中

四、缓存穿透

定义：应用请求的数据，既不在redis缓存中，也不在数据库中，后续在查询这些数据时，依然无法命中缓存，导致需要运行整个流程，服务器处理无效请求，浪费资源。

产生原因：

业务误操作，请求的是无用的数据；或者误删除一些数据，导致数据库和缓存中都没有了数据。

恶意攻击，专门访问没有的数据，去拖垮服务。

解决思路：

缓存空值或者缺省值：也就是当缓存穿透时，查询数据没有值时，在缓存中缓存这个空值，或者给一个默认给定的值，当有这个无效数据再来访问时，可以命中缓存。

使用布隆过滤器进行拦截，判断数据是否存在数据库中。