本文共 871 字，大约阅读时间需要 2 分钟。

Cache Aside Pattern

最经典的缓存+数据库读写的模式，就是 Cache Aside Pattern。

读的时候，先读缓存，缓存没有的话，就读数据库，然后取出数据后放入缓存，同时返回响应。

三种方案如下：

• 串行化可以保证一定不会出现不一致的情况，但是它也会导致系统的吞吐量大幅度降低，高并发下效率大大降低。
• 先更新数据库，再删除缓存

为什么是删除缓存，而不是更新缓存？

原因很简单，很多时候，在复杂点的缓存场景，缓存不单单是数据库中直接取出来的值。更新操作开销大多，而这一时段如果读少则造成程序的开销增大。

这种方案也是程序在用的，同时也是与程序松耦合的方案。针对数据库更新成功，缓存删除失败的情况，canal监控到变化则数据库更新成功，缓存删除失败增加了消息队列进行重试机制。

canal监控mysql的变化，如果数据更新，则进行删除缓存操作，如果删除缓存失败，则把删除操作放入消息队列中，自己进行消费该消息进行删除重试。

图片以及这种方案详细内容来源

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

更新数据库的时候，根据数据的唯一标识，将操作路由之后，发送到一个 jvm 内部队列中。读取数据的时候，如果发现数据不在缓存中，那么将重新读取数据+更新缓存的操作，根据唯一标识路由之后，也发送同一个 jvm 内部队列中。

即更新数据库缓存操作，读取数据时（缓存不存在）放到内存队列中，同时读取数据等待队列处理超时问题（超时先查询数据库返回）

高并发的场景下，该解决方案要注意的问题：

• 读请求长时阻塞

超时返回，同时提前做好服务到压测跟预估

• 读请求并发量过高
• 多服务实例部署的请求路由

nginx路由到相同服务事例上

• 热点商品的路由问题，导致请求的倾斜

更多详细的介绍参看文章：

总结：

其实秒杀商品的库存大部分都是存放到redis中，库存只更新缓存的。

先删除缓存再更新数据库，存在缓存击穿问题（大量读请求过来，都走了数据库），同时增加了代码复杂性。

先更新数据库，再删除缓存，通过松耦合的情况，大部分场景能满足。

当然特殊场景需要特殊策略对待。

转载地址：http://ogadi.baihongyu.com/