35. 经典问题——先更新数据库，还是先更新缓存

高频问题：应用缓存以后，缓存和数据库何时同步？

数据不一致问题

除了少部分配置信息类缓存，比如业务中的黑白名单信息，页面展示配置等
大部分缓存应用一般是作为前端请求和持久化存储的中间层，承担前端的海量请求

20230719145240.jpg

更新缓存有哪些方式

缓存更新方案是通过对 更新缓存和更新数据这两个操作的设计，实现数据的最终一致性
前端请求的读操作先从缓存中查询数据，如果没有命中数据，则查询数据库
从数据库查询成功后，返回结果，同时更新缓存
如果数据发生了更新操作，必须要考虑如果操作缓存，保证一致性

先更新数据库，再更新缓存

在写操作中，先更新数据库，更新成功后，再更新缓存
由于缓存和数据库是分布式的，更新缓存可能会失败
会出现数据时新的，缓存中的数据是旧的

先删除缓存，再更新数据库

在数据更新时，首先删除缓存，再更新数据库
假如某次的更新操作，更新了商品详情A 的价格，线程A 进行更新时失效了缓存数据
线程 B 此时发起一次查询，发现缓存为空，于是查询数据库并更新缓存
然后线程A 更新数据库为新的价格

先更新数据库，再删缓存

经典的缓存+数据库读写的模式，有些资料称它为 Cache Aside 方案
具体操作：读的时候，先读缓存，缓存没有的话，读数据库，然后取出数据后放入缓存，同时返回响应。更新的时候，先更新数据库，数据库更新成功之后再删除缓存。

对缓存更新的思考

• 在实际业务中，缓存的数据也行来自于多张底层数据表的聚合。比如商品详情信息，如果更新了一个价格字段，就要更新整个数据库
• 不是所有的缓存数据都是频繁访问的，更新后的缓存可能会长时间不被访问

更好的方案：更新时删除缓存，等到下次查询命中再填充缓存
Lazy Loading —— 适用于加载代价大的操作

多级缓存如何更新

多级缓存比较难保证数据一致性，通常用在对数据一致性不敏感的业务中
比如新闻资讯，电商用户评论模块等
在具体业务中，需要有针对地进行设计

• 通过给数据添加版本号，或通过时间戳 + 业务主键的方式，控制缓存的数据版本来实现最终一致性
• 通过 Binlog 异步更新缓存