如何保证缓存与数据库的双写一致性？
最经典的缓存+数据库读写的模式。
- 读的时候，先读缓存，缓存没有的话，就读数据库，然后取出数据后放入缓存，同时返回响应。
- 更新的时候，先删除缓存，再更新数据库。
为什么是删除缓存而不是更新缓存？
举个例子，比如说我一条数据，1分钟内修改了10次，那么缓存更新 10 次；但是这个缓存在 1 分钟内可能只被读取了 1 次，那每次更新的意义就不大，还会增加开销。如果你只是删除缓存的话，那么在 1 分钟内，这个缓存不过就重新计算一次而已，开销大幅度降低。用到缓存才去算缓存。
为什么先删除缓存再更新数据库，而不是先更新数据库再删除缓存？
先更新数据库，成功了再删除缓存。如果删除缓存失败了，那么会导致数据库中是新数据，缓存中是旧数据，数据就出现了不一致。
先删除缓存，成功了再更新数据库。如果数据库更新失败了，那么数据库中是旧数据，缓存中是空的，那么数据不会不一致。因为读的时候缓存没有，所以去读了数据库中的旧数据，然后更新到缓存中还是旧数据，数据还是一致的，所以没问题
比较复杂的数据不一致问题分析比如：数据发生了变更，先删除了缓存，然后要去修改数据库，此时还没修改。一个请求过来，去读缓存，发现缓存空了，去查询数据库，查到了修改前的旧数据，放到了缓存中。随后数据变更的程序完成了数据库的修改。完了，数据库和缓存中的数据不一样了
解决方案：加锁，比如redisson分布式锁，缺点：串行变成并行，效率更低了
优化方案：
一： 对于读多写少的场景：
了解下分布式读写锁，读锁和读锁之间可以并行，不互斥，所以不影响读的效率； 对同一个产品加写锁时，读锁就要等待， 以下，读锁，多个线程进来时，相当于没有加锁，不影响。只有写锁生效时，读锁才会 等待
以下是写锁
二： 对于读多写多的场景
对于这种情况，大多数互联网公司没那么多要求保证实时的。比如商品详情页面上的库存，有时候并不是真正的库存。要到下单的时候才会去数据库取库存。所以。这种情况。我们只需要库存设置为缓存的时候，设置个超时时间为1分钟就行。
