Cache Aside Pattern
最经典的缓存+数据库读写的模式,就是 Cache Aside Pattern。
读的时候,先读缓存,缓存没有的话,就读数据库,然后取出数据后放入缓存,同时返回响应。
三种方案如下:
- 串行化可以保证一定不会出现不一致的情况,但是它也会导致系统的吞吐量大幅度降低,高并发下效率大大降低。
- 先更新数据库,再删除缓存
为什么是删除缓存,而不是更新缓存?
原因很简单,很多时候,在复杂点的缓存场景,缓存不单单是数据库中直接取出来的值。更新操作开销大多,而这一时段如果读少则造成程序的开销增大。
这种方案也是程序在用的,同时也是与程序松耦合的方案。针对数据库更新成功,缓存删除失败的情况,canal监控到变化则数据库更新成功,缓存删除失败增加了消息队列进行重试机制。
canal监控mysql的变化,如果数据更新,则进行删除缓存操作,如果删除缓存失败,则把删除操作放入消息队列中,自己进行消费该消息进行删除重试。
图片以及这种方案详细内容来源http://www.cnblogs.com/rjzheng/p/9041659.html
- 先删除缓存,再更新数据库
更新数据库的时候,根据数据的唯一标识,将操作路由之后,发送到一个 jvm 内部队列中。读取数据的时候,如果发现数据不在缓存中,那么将重新读取数据+更新缓存的操作,根据唯一标识路由之后,也发送同一个 jvm 内部队列中。
即更新数据库缓存操作,读取数据时(缓存不存在)放到内存队列中,同时读取数据等待队列处理超时问题(超时先查询数据库返回)
高并发的场景下,该解决方案要注意的问题:
- 读请求长时阻塞
超时返回,同时提前做好服务到压测跟预估
- 读请求并发量过高
- 多服务实例部署的请求路由
nginx路由到相同服务事例上
- 热点商品的路由问题,导致请求的倾斜
更多详细的介绍参看文章:https://blog.csdn.net/chang384915878/article/details/86756463
https://blog.csdn.net/simba_1986/article/details/77823309
总结:
其实秒杀商品的库存大部分都是存放到redis中,库存只更新缓存的。
先删除缓存再更新数据库,存在缓存击穿问题(大量读请求过来,都走了数据库),同时增加了代码复杂性。
先更新数据库,再删除缓存,通过松耦合的情况,大部分场景能满足。
当然特殊场景需要特殊策略对待。