3种更新方法
1、写DB，然后删缓存
不可以反着来，反着来可能会出错。
这么做小概率出错，场景如下：小概率是因为3操作一般比2操作要快的多，DB毕竟慢。
1、请求1从DB读数据A
2、请求2写更新数据 A 到数据库并把删除cache中的A数据
3、请求1将数据A写入cache。
缺陷1：首次请求数据一定不在 cache 的问题
解决办法：可以将热点数据可以提前放入cache 中。
缺陷2：写操作比较频繁的话导致cache中的数据会被频繁被删除，这样会影响缓存命中率 。
解决办法：
- 数据库和缓存数据强一致场景 ：更新DB的时候同样更新cache，不过我们需要加一个锁/分布式锁来保证更新cache的时候不存在线程安全问题。
- 可以短暂地允许数据库和缓存数据不一致的场景 ：更新DB的时候同样更新cache，但是给缓存加一个比较短的过期时间，这样的话就可以保证即使数据不一致的话影响也比较小。
2、直接写缓存，缓存服务更新DB
不重要服务，可以这么搞，但是也没必要
3、直接写缓存，异步更新DB
这种策略在我们平时开发过程中也非常非常少见，但是不代表它的应用场景少，比如消息队列中消息的异步写入磁盘、MySQL 的 InnoDB Buffer Pool 机制都用到了这种策略。
