redis缓存更新策略、缓存穿透、缓存雪崩

本文主要是介绍redis缓存更新策略、缓存穿透、缓存雪崩，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

缓存穿透：用户多次查询数据库没有的数据，导致多次访问数据库，从而使数据库压力变大
   解释：用户多次连续访问数据，比如说用户查询id为101的数据时，数据库是没有的，并且用户进行了多次查询id为101的数据，那么久数据库的压力就会   很大
   如何防止缓存穿透：
       为了防止用户多次访问数据库我就可以在缓存中存一个key为101，值为空的数据，并设置一个较短的ttl，那么用户在访问同一个id的并且数据库没有的数据时，就可以       从缓存中返回空数据，防止数据库压力过大，也就是防止缓存穿透。
缓存雪崩：缓存大批量同一时间失效，导致数据库访问压力大。
       解释：
           一般设置缓存的键值对时都是有ttl的，如果说同一批次查询出的数据设置的ttl一样，那么就会在同一时间失效，   导致数据库的访问量变大，
       如何防止缓存雪崩：
           我们可以将ttl的时间设置为一个基础时间加一个随机时间，让缓存不在同一时间内失效来防止缓存雪崩

缓存更新策略：
1.内存淘汰（不用自己维护，由redis的内存淘汰机制，当内存不足时删除部分数据）（一致性差，无维护成本）
2.超时剔除（设置缓存的ttl时间，到期后自动删除缓存---问题：比如设置ttl时间为10分钟，在这期间数据库发生变化导致数据不一致）（一致性一般，维护成本低）
3.主动更新策略（推荐）（一致性好，维护成本高）
   a.在调用者更新数据库的同时更新redis（可控性比较高）（目前企业中使用的大多时这种方式）
       3.1.1：操作缓存和数据库需要考虑三个问题
           3.1.1.1：删除缓存还是更新缓存
               更新缓存：每次更新数据库的时候更新缓存，对缓存的操作属于无效操作，（比如执行了很多此更新，这个期间，没有从redis获取数据，redis就失去了作用）
               删除缓存：更新数据库时使缓存的失效 (每次执行删除或者更新操作时删除对应的缓存，保持一致性）
           3.1.1.2：如何保证数据库和缓存的操作同时成功和同时失败
               单体项目：通过事务来管理，保证同时成功，同时失败
               分布式项目：通过TCC的分布式事务方案解决（还没学会，先放这吧）
           3.1.1.3：先操作缓存还是先操作数据库
                   3.1.1.3.1 先删除数据再操作缓存(推荐）
                       存在的问题：
                           假如线程1执行了查询操作，查询id为99的数据，缓存中没有，那么该去数据库查询了，在查询出结果为10但是没有写入缓存时，线程二执行了更新id为 99的数据，并写入缓存，数据库值为20，此时线程1执行了插入缓存的数据为 10，那么就会发生数据库缓存不一致的情况。
                       解决方案：
                           一般来说，数据库的更新操作是比较长的，写入缓存是很快的，就是说在执行线程1去数据库查询出数据但是没有写入缓存，并且此时正好另外一个线程在写入缓存的时间间隔内执行了更新操作的情况的可能性很小，但不是没有，这种情况以为这更新的时间比写入缓存的时间短，我们可以考虑给写入缓存设置一个最大的时间限制，如果超过这个时间，就可以重新查询一次数据库，来更新数据
                   3.1.1.3.2先删除缓存再操作数据库（不推荐）
                       存在的问题：假如现在要更新数据id为100的值为20，线程1先删除了id为100的缓存数据，还没有去更新数据库，此时线程二查询了id为100的数据，缓存中没有，去数据库查询值为10，然后写如了缓存，此时线程1将数据数据更新为 20，那么就导致了数据库数据和缓存不一致，而且这种情况的概率很高，因为线程1更新数据库的速度是慢于线程二查询数据的速度的。
   b.缓存和数据库整合成一个服务（实现比较困难，不好找到一个现成的实现方案）
   c.调用者只操作缓存，由其他的线程异步的处理数据库（由于调用者只操作了缓存，速度很快，并且缓存的多次操作可以由线程进行批量插入进数据库，比较合适）（问题是可能存在缓存和数据库不       一致，另外数据都存在缓存中，万一缓存服务宕机可能导致数据丢失）