转载:http://zhuanlan.51cto.com/art/201807/578810.htm
读操作:
- 尝试从缓存get数据,结果没有命中;
- 从数据库获取数据,读从库,读写分离;
- 把数据set到缓存,未来能够命中缓存;
读操作的流程应该没有歧义。
写操作:
写操作,既要操作数据库中的数据,又要操作缓存里的数据。
这里,有两个方案:
- 先操作数据库,再操作缓存;
- 先操作缓存,再操作数据库;
并且,希望保证两个操作的原子性,要么同时成功,要么同时失败。
这演变为一个分布式事务的问题,保证原子性十分困难,很有可能出现一半成功,一半失败,接下来看下,当原子性被破坏的时候,分别会发生什么。
1.先数据库,再缓存
正常情况下:
- 先操作数据库,成功;
- 再操作缓存(delete或者set),也成功;
但如果这两个动作原子性被破坏:第一步成功,第二步失败,会导致,数据库里是新数据,而缓存里是旧数据,业务无法接受。
画外音:如果第一步就失败,可以返回调用方50X,不会出现数据不一致。
2.先缓存,再数据库
正常情况下:
- 先操作缓存(delete或者set),成功;
- 再操作数据库,也成功;
画外音:如果第一步就失败,也可以返回调用方50X,不会出现数据不一致。
如果原子性被破坏,会发生什么呢?
这里又分了两种情况:
- 操作缓存使用set
- 操作缓存使用delete
使用set的情况:第一步成功,第二步失败,会导致,缓存里是set后的数据,数据库里是之前的数据,数据不一致,业务无法接受。
并且,一般来说,数据最终以数据库为准,写缓存成功,其实并不算成功。
使用delete的情况:第一步成功,第二步失败,会导致,缓存里没有数据,数据库里是之前的数据,数据没有不一致,对业务无影响。只是下一次读取,会多一次cache miss。
画外音:此时可以返回调用方50X。
最终,先操作缓存,还是先操作数据库?
答:
(1) 读请求,先读缓存,如果没有命中,读数据库,再set回缓存
(2) 写请求
- 先缓存,再数据库 (最终已数据库为准的话,我自己觉得先数据库也是可以的。数据库失败就不更新缓存。)
- 缓存,使用delete,而不是set (如果对象很大的话,当然删除更快。delete相对来说更好,只不过多了一次cache miss而已。)