缓存更新形式
很多研发同学是这么用缓存的：在查问数据的时候，先去缓存中查问，如果命中缓存那就间接返回数据。如果没有命中，那就去数据库中查问，失去查问后果之后把数据写入缓存，而后返回。在更新数据的时候，先去更新数据库中的表，如果更新胜利，再去更新缓存中的数据。流程如下图
这样应用缓存的形式有没有问题？绝大多数状况下都没问题。然而，在并发的状况下，有肯定的概率会呈现“脏数据”问题，缓存中的数据可能会被谬误地更新成了旧数据。比方 1，对同一条记录，同时产生了一个读申请和一个写申请，这两个申请被调配到两个不同的线程并行执行，读线程尝试读缓存没命中，去数据库读到了数据，这时候可能另外一个写线程领先更新了缓存，在解决写申请的线程中，先后更新了数据和缓存，而后，拿着旧数据的第一个读线程又把缓存更新成了旧数据（概率低）。比方 2 两个线程对同一个条订单数据并发写，也有可能造成缓存中的“脏数据”（概率高）
1、故咱们常常应用 Cache Aside 模式，它们解决读申请的逻辑是齐全一样的，惟一的一个小差异就是，Cache Aside 模式在更新数据的时候，并不去尝试更新缓存，而是去删除缓存。流程如下：
这种形式能够解决如上例子 2 中的脏数据的问题。在写策略中，是否先删除缓存，后更新数据库呢？答案是不行的，因为这样会大大提高如上事例 1 呈现的概率。另外咱们个别会配合增加一个比拟短的过期工夫，即便示例 1 的状况呈现了，也只有比拟短时间的脏数据。
但也要学会依状况而变。比如说新注册用户，依照这个更新策略，要写数据库，而后清理缓存。可当注册完用户后，当应用读写拆散时，会呈现因为主从提早所以读不到用户信息的状况（一致性要求比拟高的话，写后读在肯定工夫阈值外面个别去 master 读，此时就不会有这个问题，我会在一致性浅谈的文章里介绍）。而解决这个问题的方法恰好是在插入新数据到数据库之后写入缓存，这样后续的读申请就会从缓存中读到数据了，因为是新注册的用户，所以不会呈现并发更新状况。
2、另一种常常应用的策略是模仿 MySQL 的从机，通过订阅 binlog 的形式更新缓存，此时 MySQL 必须设置为 row 格局。个别流程图如下：
缓存穿透
如果咱们的缓存命中率比拟低，就会呈现大量“缓存穿透”的状况。缓存穿透指的是，在读数据的时候，没有命中缓存，申请“穿透”了缓存，间接拜访后端数据库的状况。大量的缓存穿透是失常的，咱们须要预防的是，短时间内大量的申请无奈命中缓存，申请穿透到数据库，导致数据库忙碌，申请超时。大量的申请超时还会引发更多的重试申请，更多的重试申请让数据库更加忙碌，这样恶性循环最终导致系统雪崩。
1、当零碎初始化的时候，比如说系统升级重启或者是缓存刚上线，这个时候缓存是空的，如果大量的申请间接打过去，很容易引发大量缓存穿透导致雪崩。为了防止这种状况，能够采纳灰度公布的形式，先接入大量申请，再逐渐减少零碎的申请数量，直到全副申请都切换实现。如果零碎不能采纳灰度公布的形式，那就须要在系统启动的时候对缓存进行预热：在零碎初始化阶段，接管内部申请之前，先把最常常拜访的数据填充到缓存外面，这样大量申请打过去的时候，就不会呈现大量的缓存穿透了。
2、当有大量的申请拜访不存在的数据时，比方在券商零碎的用户表中，咱们须要通过用户 ID 查问用户的信息。如果要读取一个用户表中未注册的用户，依照这个策略，咱们会先读缓存再穿透读数据库。因为用户并不存在，所以缓存和数据库中都没有查问到数据，因而也就不会向缓存中回种数据，这样当再次申请这个用户数据的时候还是会再次穿透到数据库。在这种场景下缓存并不能无效地阻挡申请穿透到数据库上，它的作用就微不足道了。一般来说咱们会有两种解决方案：回种空值以及应用布隆过滤器
第一种解决方案回种空值。当咱们从数据库中查问到空值或者产生异样时，咱们能够向缓存中回种一个空值。然而因为空值并不是精确的业务数据，并且会占用缓存的空间，所以咱们会给这个空值加一个比拟短的过期工夫，让空值在短时间之内可能疾速过期淘汰。回种空值尽管可能阻挡大量穿透的申请，但如果有大量获取未注册用户信息的申请，缓存内就会有有大量的空值缓存，也就会节约缓存的存储空间，如果缓存空间被占满了，还会剔除掉一些曾经被缓存的用户信息反而会造成缓存命中率的降落。所以这个计划，在应用的时候应该评估一下缓存容量是否可能撑持。
第二种解决方案布隆过滤器。布隆过滤器有一个特点是：布隆过滤器如果返回不存在的那么肯定是不存在的，然而如果返回存在，未必存在。如果布隆过滤器的屡次 hash 函数抉择的比拟正当，空间预估的比拟正当，那边布隆过滤器返回存在，然而不存在的概率是很小的。故咱们能够应用这一个性。如新注册的用户除了须要写入到数据库中之外，同时更新用户 ID 到布隆过滤器。那么当咱们须要查问某一个用户的信息时，先查问这个 ID 在布隆过滤器中是否存在，如果不存在就间接返回空值，而不须要持续查询数据库和缓存，这样就能够极大地缩小异样查问带来的缓存穿透。
3、热点 KEY 问题，依照上文介绍的缓存更新形式（缓存 + 过期工夫），以后 KEY 是一个热点 KEY，有大量的并发申请并且重建缓存不能再很短时间内实现。那么在缓存生效的霎时，有大量申请来重建缓存，造成后端负载加大，甚至雪崩。这个问题的根本原因是有大量的申请拜访了后端存储，故咱们能够从缩小拜访后端申请的角度解决问题：
第一种办法是互斥锁计划：此办法只容许同一时刻只有一个线程更新缓存，具体的是在更新的时候申请互斥锁，获取到锁的线程更新缓存，其余线程期待更新实现。这种办法思路比较简单，然而可能存在死锁的危险，并且线程池可能会梗塞。
第二种办法是永远不过期：从缓存层面，不设置过期工夫，从而不会呈现热点 KEY 过期后产生的问题；从性能层面，为每个 value 设置逻辑过期工夫，当发现超过逻辑过期工夫后应用独自的线程重建缓存。逻辑过期工夫减少了代码复杂度和内存老本。
4、大量 KEY 同时拜访的问题，依照上文介绍的缓存更新形式（缓存 + 过期工夫），当有大量的 KEY 同时拜访，那么他们的过期工夫也是一样的，这个会导致很多缓存项同时过期，从而可能导致缓存的机器资源占用高（缓存在同一时间淘汰大量的缓存项），另外下次大量并发申请过去的时，就须要重建大量的缓存，从而导致缓存穿透甚至雪崩。解决办法也很简略，就是更新缓存的时候增加一个随机的过期工夫（缓存 + 过期工夫 + 随机工夫）