由于缓存和数据库是分开的，无法做到原子性的同时进行数据修改，可能出现缓存更新失败，或者数据库更新失败的情况，这个时候出现数据不一致，影响前端业务。
1.先更新数据库，再更新缓存，这个时候缓存可能更新失败，读到老数据。 2.先删除缓存，再更新数据库，在高并发情况下，读操作可能还是会将旧数据读回缓存。 3.先更新数据库，再删除缓存。也存在缓存删除失败的可能。 最经典的缓存+数据库读写模式： 读的时候，先读缓存，缓存没有的话，就读数据库，然后去除数据放入缓存，同时返回响应。更新的时候，先更新数据库，然后删除缓存。
删除更加轻量，延迟加载的一种实现，更新的时候可能涉及到多个表，比较耗时
延时双删：先删除缓存，再更新数据库，休眠1s，再次删除缓存。写数据的休眠时间则在读数据业务逻辑的耗时基础上，加几百ms即可。这么做的目的，就是确保读请求结束，写请求可以删除读请求造成的缓存脏数据，并发还是可能读到旧值覆盖缓存。
终极方案： 将访问操作串行化 1.先删除缓存，将更新数据库的操作放进有序队列中 2.从缓存查不到的查询操作，都进入有序队列 会面临的问题： 1.读请求积压，大量超时，导致数据库的压力：限流，熔断 2.如何避免大量请求积压：将队列水平拆分，提高并行度。 3.保证相同请求路由正确。
