本文探讨了在数据变化时，缓存更新的四种策略：先更新缓存再更新数据库、先删除缓存再更新数据库、先更新数据库再更新缓存以及先更新数据库再删除缓存。通过分析并发场景，指出先更新数据库再删除缓存的策略（Cache-Aside pattern）在实际应用中能较好地保证数据一致性，虽然可能存在并发问题，但可以通过异步延时删除策略和消息重试机制进行优化。
缓存更新
缓存（Redis、memory cache等）被广泛应用于高并发、高性能的项目中。应用在，请求先查询缓存，命中则返回。未命中则查询数据库，并缓存。而且缓存也有过期时间的，避免浪费内存、出现不一致等，因此缓存是最终一致性的。但实际使用中，需要主动更新缓存。那就存在一个问题：为保证数据读取的正确性、一致性，是先更新缓存，还是先更新数据库？
数据变化时，缓存可以更新也可以删除，等查询的时候再次缓存即可。因此可以组合出以下四种策略：
先更新缓存，再更新数据库；
先删除缓存，再更新数据库；
先更新数据库，再更新缓存；
先更新数据库，再删除缓存；
上述策略都是两步操作完成。下边依次来分析这四种策略的可行性。
先更新缓存，再更新数据库
两步：第一步更新缓存，第二步更新数据库。
场景
1.线程A 尝试更新数据库，第一步更新缓存
2.线程B 尝试更新数据库，第一步更新缓存
3.线程B 第二步更新数据库
4.线程A 第二步更新数据库
此时，因为线程B 在线程A之后完成了缓存更新，但先更新了数据库。即 A-B-B-A，导致缓存中是线程B 设置的数据。在一个Ttl内，数据不一致。
先删除缓存，再更新数据库
场景
1.线程A 尝试更新数据库，第一步更新缓存
2.线程B 读缓存，未命中，继续读数据库，并缓存。（此
最低0.47元/天 解锁文章
扫一扫
1134
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
