之所以为缓存新建一个文集，是因为这个知识点实在是太重要了，在项目中用redis + springCache做缓存的代码差不多写完了，这里稍微做下笔记，全为脑中零散记忆，属个人理解，有错望纠！

参考文章和这篇

缓存击穿

当某个缓存key过期后，突然在缓存更新的间隔内超高并发的对这缓存key的请求压力全部落在数据库上，这就是缓存击穿！

黑客可以利用这点，对一些不存在的数据发出大量请求，这些没有被缓存的数据没有存在于缓存中，造成数据库压力过大直至崩溃。

缓存击穿的解决方案

缓存雪崩

如果缓存垮掉，如果之前没有做好容量预估，所有请求都压在DB上，致使数据库也跨掉造成整体服务不可用。
解决方案：

• 自动故障转移
  redis就有哨兵模式，当主从服务器的主服务器崩溃不可写时，哨兵检测到，采用某些策略从从服务器中投票选出某一个来当主服务器，其他从服务器称为其从服务器。
• 水平切分
  使用多台服务器分担请求压力，当一台服务器崩掉，还有其他服务器工作，但这种方式会造成数据不一致等问题，预防会使逻辑复杂！

数据库读写缓存一致性问题

此缓存一致性问题是指数据请求时造成的缓存和数据库数据不一致的问题！

cache更新？淘汰？

在修改数据时，对于缓存中的数据进行删除还是更新，由具体业务情况而定。

• 淘汰数据的话，会增加后面请求一次cache miss的情况。
• 更新数据的话，逻辑相对较复杂。

业务举例
在某网上商城买件衣服，缓存中已有用户信息：
1.首先从数据库查询该衣服价格70
2.从数据库中获取折扣信息，获取优惠券信息。
3.从cache中获取用户余额100
4.100-70=30计算后写入缓存
5.然后获取cache中用户拥有该道具件数
6.件数加一写回缓存
为了避免一次cache miss，要读写数据库缓存多次（或更复杂的情况），逻辑还复杂了，不值当！
而如果直接是将余额改为200，仅仅一个简单的set（balance， 200）就可以直接更新缓存了！

先操作DB，还是先操作cache

操作数据时，到底是先操作缓存还是先操作数据库？

先cache再DB

先缓存在数据库会造成并发读写时的缓存一致性问题。
如：

1. A要更新某数据key，先淘汰cache中的key
2. 淘汰key后，B需要读key，cache miss
3. 因为写比较慢，或者A在主DB中写完成，为完成主从数据同步，B从从数据库读取到已经原来的数据。
4. A更新数据库
5. B将脏数据写入缓存
   此时缓存和数据库数据不一致。在一个过期时间内，其他的读请求读取的全是脏数据！

先DB再cache

此种情况一般不会发生缓存一致性问题。
比如：A读，B写

• A在B的前面：
  • cache miss
    1.A读取DB原数据
    2.B更新数据
    3.B删除缓存（即使没有缓存）
    4.A写缓存（脏数据）
    此时数据库和缓存数据一致，但这种情况很少发生，因为写操作一般都比读操作慢，不可能B更新数据再删除缓存之后A才读完数据。所以要不3、4颠倒，缓存数据被删除，数据也不会不一致！
  • cache hit
    这种情况最多导致B写完到删除缓存这段时间内读取的数据不一致，即删除缓存的时间，最终数据还是一致的！
• B在A的前面同理，
  • cache miss
    因为写比较慢即使A读取到脏数据，写入了缓存，也会被慢一步的B删除，最终数据还是一致的！
  • cache hit，这种更不用说，写完DB到删除cache之间的读不一致，可以忽略。

所以先DB在cache的策略还是可以在很大程度上避免并发读写导致的缓存一致性问题的！

但是，如果出现原子性问题（先cache再DB没有），B的写操作成功，删除缓存操作失败，也会造成缓存一致性问题。解决方案：将删除失败的key加入到消息队列中，尝试多次删除直到正确删除为止！

cache-aside pattern

国外有人提出《cache-aside patter》套路，即旁路缓存方案的经验实践，这个实践又分读实践，写实践。
读先cache后DB，cache hit返回数据，cache miss访问DB，然后将数据写入到缓存！
写先DB在cache，先更新数据库，再淘汰cache！

注意，其建议删除缓存，因为并发写缓存可能会发生错误造成数据不一致！