缓存实践Cache Aside Pattern
2024-08-31 00:59:13
Cache Aside Pattern旁路缓存，是对缓存应用的一个总结，包括读数据方案和写数据方案。
读数据方案
- 先读cache，如果命中则返回
- 如果miss则读db
- 将db的数据存入缓存
写数据方案
写数据的过程包括了两个问题，更新cache的策略和操作db与cache的顺序。更新cache有两种策略：直接更新cache，和删除cahce。操作db和cache的顺序有先db再cache，和先cache再db。那么就会组合出四种方案：
- 先更新db再更新cache
- 先更新db再删除cache
- 先更新cache再更新db
- 先删除cache再更新db
Cache Aside Pattern采用的是第2种方案先更新db再删除cache：
- 先更新数据到db
- 再删除缓存
其他方案为啥不用呢？
第1种方案：先更新db再更新cache
更新cache比删除cache更直接，也不会在查询时候再从db查询一次，但是这个方案有缺陷，更新db和更新cache是两个操作，不在一个事务，假如有两个线程同时写数据：
- 线程1先更新了db
- 线程2也更新了db
- 线程2又更新了cache
- 线程1更新了cache
此时db的数据是线程2的，而cache的数据是线程1的，db和cache不一致了。。。此方案无法保证多线程并发时db和ache的一致性。而如果采用删除缓存则不会出现问题。
第3种方案：先更新cache再更新db
这个方案和方案方案1存在同样的问题：无法保证多线程并发时db和ache的一致性。
第4种方案：先删除cache再更新db
如果有两个线程，线程1写数据，线程2读数据：
- 线程1将cache删除
- 线程2读数据miss
- 线程2读取db数据
- 线程2将db数据写入缓存
- 线程1将数据更新到db
又悲剧了，cache里面是旧数据。。。
写数据最好的方案是先更新db再删除cache
最后说明一点，Cache Aside Pattern并没有解决分布式事务问题。分布式事务比较复杂，一般保证db和cache的强一致比较困难。根据CAP理论，为保证可用性场景，可以用最终一致性方案解决。
---恢复内容结束---
最新文章
- 你真的会玩SQL吗？Case也疯狂
- OPENGL半透明图像产生黑色光环
- GSM Hacking Part① ：使用SDR扫描嗅探GSM网络
- select 多表查询
- C# ReferenceEquals(), static Equals(), instance Equals(), 和运算行符==之间的关系
- OpenCV学习 6：平滑滤波器 cvSmooth()——2
- SQL Server2008数据库中删除用户，提示数据库主体在该数据库中拥有 架构，无法删除
- [转载]AI教师正来势汹汹，教师饭碗堪优
- spring4笔记----Spring几种常用的容器后处理器
- ubuntu12.04+cuda6.0+caffe（新版）的安装
- springMVC源码分析--视图AbstractView和InternalResourceView（二）
- Windows Phone 常用资源
- Java多线程--线程及相关的Java API
- ICE简介及C++程序例子(转)
- 【用jersey构建REST服务】系列文章
- iOS开发学习-cocoapods的配置安装
- JavaScrip——练习(做悬浮框进一步：悬浮窗后缀悬浮窗【感觉这种方法比较麻烦】)
- C# 为VB6.0程序模拟串口数据
- .htaccess文件
- scanf输入字符串相关