Redis更新的正确方法

原文&＃xff08;缓存更新的套路&＃xff09;&＃xff1a;看到好些人在写更新缓存数据代码时&＃xff0c;先删除缓存&＃xff0c;然后再更新数据库&＃xff0c;而后续的操作会把数据再装载的缓存中。然而&＃xff0c;这个是逻辑是错误的。试想&＃xff0c;两个并发操作&＃xff0c;一个是更新操作&＃xff0c;另一个是查询操作&＃xff0c;更新操作删除缓存后&＃xff0c;查询操作没有命中缓存&＃xff0c;先把老数据读出来后放到缓存中&＃xff0c;然后更新操作更新了数据库。于是&＃xff0c;在缓存中的数据还是老的数据&＃xff0c;导致缓存中的数据是脏的&＃xff0c;而且还一直这样脏下去了。

视图分析&＃xff1a;

写流程&＃xff08;更新策略&＃xff09;

1. 先淘汰 cache&＃xff08;删除缓存&＃xff09;&＃xff1b;
2. 再写 DB&＃xff08;更新数据库&＃xff09;。

读流程

1. 先读 cache&＃xff0c;如果数据命中 hit 则返回&＃xff1b;
2. 如果数据未命中 miss 则读 DB&＃xff1b;
3. 将 DB 中读取出来的数据入缓存。

什么情况下可能出现缓存和数据库不一致呢&＃xff1f;

在分布式环境下&＃xff0c;数据的读写都是并发的&＃xff0c;上游有多个应用&＃xff0c;通过一个服务的多个部署&＃xff08;为了保证可用性&＃xff0c;一定是部署多份的&＃xff09;&＃xff0c;对同一个数据进行读写&＃xff0c;在数据库层面并发的读写并不能保证完成顺序&＃xff0c;也就是说后发出的读请求很可能先完成&＃xff08;读出脏数据&＃xff09;&＃xff1a;

1. 发生了写请求 A&＃xff0c;A 的第一步淘汰了 cache&＃xff08;如上图中的1&＃xff09;&＃xff1b;
2. A 的第二步写数据库&＃xff0c;发出修改请求&＃xff08;如上图中的2&＃xff09;&＃xff1b;
3. 发生了读请求 B&＃xff0c;B 的第一步读取 cache&＃xff0c;发现 cache 中是空的&＃xff08;如上图中的步骤3&＃xff09;&＃xff1b;
4. B 的第二步读取数据库&＃xff0c;发出读取请求&＃xff0c;此时 A 的第二步写数据还没开始&＃xff0c;读出了一个脏数据放入 cache&＃xff08;如上图中的步骤4&＃xff09;。

最终导致缓存与数据库不一致。

先更新数据库&＃xff0c;后删除缓存&＃xff08;建议&＃xff0c;使用场景最多&＃xff09;&＃xff0c;但是&＃xff0c;是不是这个就不会有并发问题了&＃xff1f;不是的&＃xff0c;比如&＃xff0c;一个是读操作&＃xff0c;但是没有命中缓存&＃xff0c;然后就到数据库中取数据&＃xff0c;此时来了一个写操作&＃xff0c;写完数据库后&＃xff0c;让缓存失效&＃xff0c;然后&＃xff0c;之前的那个读操作再把老的数据放进去&＃xff0c;所以&＃xff0c;会造成脏数据。