为了更快响应请求，减少不必要的查询，加速数据的处理，数据缓存是我们日常开发绕不过去的环节
关注公众号，一起交流，微信搜一搜: 潜行前行
缓存的意义
数据的保存，离不开磁盘或者内存的操作。为了永久性的保存，数据最终还是会同步到磁盘上，小流量小并发的系统，直接使用 mysql 进行数据的操作即可满足需求。但面对高并发大流量时，又应该怎么去更新保存读取数据呢？使用内存作为缓冲区，即缓存。CPU 操作内存空间的速度是比磁盘快一个大级别的，内存操作就是在公路上开汽车，磁盘读写则在小道上骑自行车
- 基于内存去做缓存，有两种方案：一是基于本地内存实现，如简单使用 HashMap，guava 的 LoadCache，Caffeine；二是依赖局域网中的其他中间件，如 redis，Memcache，SQLite。这些内存数据库广泛地被当做分布式缓存中间件使用
- 把数据拦截在内存上去操作，确实是提高了系统的性能。但是内存上的数据容易丢失，万一停电，机器宕机，数据全就没了，而且内存的硬件贵，容量小，并不是一个保存数据永久之地。因为我们最终还是要把数据同步到磁盘DB上，而同步就会出现一致性的问题
缓存的不一致性
- 读一致性：先读取缓存数据，有数据则直接返回；如果读取不到，则读取DB上的数据，然后给缓存的数据设置过期时间，避免数据永久停留在内存上。读一致性问题不大
- 写一致性：这里的写是专指新增的操作。和读操作差不多，直接写入数据库即可，如果后续有读操作，则使用读一致性的操作步骤即可保证一致性
- 更新一致性：更新操作则有点麻烦，有两个问题：一是先更新缓存呢，还是删除缓存？二是先操作缓存还是 DB ? 两个问题组合起来就有四种方案了，各位带着问题往下看
先更新缓存后更新DB
这个方案基本不可能会被采用的，因为出了问题是不可挽回的。想一想在多线程操作的情况下
为啥说这个方案不会被采用呢？设想用户下单的场景。第一步：更新缓存里下单状态为成功（假设此时会预定库存）；第二步读取到下单成功状态，然后准备去支付（此时第三步更新DB失败了）
- 假设支付阶段，读取到缓存里的下单状态为成功，最终支付完成。因为下单阶段会预定库存，但实际 DB 更新失败，这将导致超卖。收了钱却没货发，等着被起诉吧，或者赔偿用户
- 假设支付阶段，刚好缓存失效，读取到 DB 里的真实下单状态，支付失败。给用户的感觉就是垃圾产品
先更新DB后更新缓存
先更新数据库后更新缓存同样会存在数据不一致性，请看以下场景
网络问题可能会导致线程B更新缓存比线程A更快，而在第四步完成之后，缓存失效之前，缓存和数据库就会存在不一致性问题
- 将更新DB和更新缓存操作封装在同一个事务？虽然可以做到强一致性，但这导致数据库事务的延长，会导致服务性能下降，本来引入缓存是为加大性能，怎么反向操作了
- 可能你会认为不一致只是短暂的，可以接受，数据最终还是会达成一致性的。但是下面还有更好的方案为啥要选这个呢？
- 还有如果写操作多，读操作少，这种方案就会导致，数据压根还没读到，缓存就被频繁的更新，浪费系统资源
- 还有些场景，数据是要经过复杂的计算才写入缓存的，而并非写入数据库的那个数据。在读少写多的业务，这多出的计算操作也是浪费系统资源的
先删缓存后更新DB
看一下先删缓存后更新DB方案
- 这个方案比更新DB后更新缓存好的地方在于，不用事先计算缓存，更新缓存
- 但在第四步操作后，先删缓存后更新DB一样存在短暂的不一致性，怎么办？可以采用 延迟双删方案
延迟双删方案
可以看到延迟双删方案增加了一步骤，在更新完数据之后，延迟一段时间再删除缓存。至于这几毫秒怎么确定，则需要同学们自己根据相应服务数据的读操作耗时时间确定。延迟删除时间 = 读操作耗时时间 + 浮动时间（大概几十毫秒就行）
- 延迟双删方案不能完美做到杜绝 缓存和DB不一致现象发生，只是极大概率减少数据不一致
先更新DB后删缓存
该方案也是不能完美解决不了数据的不一致性，但同样可以延迟删除的策略来降低数据不一致性的发生概率
- 对比先删缓存后更新DB方案，优化的点在于少了一次删除操作
延迟删除
删除失败，怎么补救
延迟删除，会不会存在删除失败的情况呢，这时怎么办。可以采用下面两种策略来补救
- 删除缓存重试机制
- 读取biglog异步删除缓存
- 删除缓存重试机制有一个缺点，对业务线代码造成大量的侵入
- 读取biglog异步删除缓存方案：专门启动一个更新缓存程序去订阅数据库的binlog，获得需要操作的数据，然后在进行更新缓存操作