缓存架构设计细节二三事 (查看原文)

本文主要讨论这么几个问题: (1)“缓存与数据库”需求缘起 (2)“淘汰缓存”还是“更新缓存” (3)缓存和数据库的操作时序 (4)缓存和数据库架构简析 一、需求缘起 场景介绍...

mp.weixin.qq.com  by 58沈剑  
评论 (17)
Default avatar

水清雨 2016-03-28 08:10

对于集群应用来说,某一个节点更新数据库淘汰缓存,但其他节点并没有意识到要淘汰缓存,这一般怎么破
Thumb

熊小二出没 2016-03-28 08:45

以你的现实场景中已经考虑过不用中心缓存为前提。 之前想到的一个方案是:对于比较敏感的数据通过广播时间来通知其它节点的数据失效。如果不失效,直接更新的话,要注意加时间戳或其它方式防止高并发下老数据覆盖新数据。对于不敏感的数据,就把节点缓存时间设置为5-6秒,快速过期吧。
Default avatar

u201958 2016-03-28 09:04

吐槽
Thumb

鸣鸣羊 2016-03-28 09:16

是否应该引入“先淘汰缓存 再写数据库 最后再淘汰一次缓存”来保证数据的一致性?
Thumb

czmonster 2016-03-28 09:30

先淘汰缓存再更新数据库的顺序不太理解,这里无法保证事务吗?淘汰缓存成功但更新数据库失败那整个业务进行失败应该就直接回滚了吧?还是说事务控制的粒度比较细,将这两个动作当两个事务处理?
Thumb

zhou7758437 2016-03-28 12:15

个人觉得淘汰缓存和更新缓存都需要相同的计算余额的过程,所以这不能成为不用更新的理由,其实应该是缓存容量的限制使得不得不做淘汰策略
Thumb

u205043 2016-03-28 13:43

缓存就盖干缓存该干的事儿,强调跟数据库一致干啥..... 如果要跟数据库一致并且有缓存的速度就用内存数据库啊。 服务化把缓存放在底层就更不靠谱了,还举余额的例子,金钱相关的还能用文中所谓的缓存么? 建议是啥角色就干啥角色该干的事儿
Thumb

giraffe 2016-03-28 17:39

假如先淘汰缓存,在更新数据库。如果淘汰缓存时就失败了呢?
Thumb

lrwin 2016-03-28 20:46

一家之谈,我认为更新缓存策略为优先考虑,笔者说的淘汰策略常用,不敢苟同
Thumb

u187048 2016-03-28 22:22

可以优先使用内存缓存,分布式同步,在内存中压常用数据,减少走网络。
Thumb

u157012 2016-03-28 22:47

不是很清晰。更新和淘汰都需要操作。另外淘汰在前数据库在后似乎也不是很正确。db失败了数据还是cache中原来的数据啊。
Thumb

u202578 2016-03-29 07:36

金额不适合用缓存
Thumb

aximo 2016-03-29 09:10

这片文章我还是比较挺楼主的 淘汰是最简单的实现方式,能极大的分离关注点,也不需要考虑数据库失败的场景,至于有人说淘汰失败,这种概率很小,且不会对数据一致性造成影响。往往缓存并非和数据库的数据存在一一对应,更新可以认为是失效之后的二次加载,当然部分更新缓存另论,但不建议这样做。 db失败之后,由于db数据还是之前的数据,二次加载依然是数据库的数据,所以也没有问题 还有人说内存数据库的是,这本来就是两件事。决定上不上内存数据库,不是以需不需要做缓存来决定的。缓存必须考虑一致性,但是在某些场景一致性不是很重要。缓存在任何层面都存在,包括硬件层,os层,应用层。所以缓存放底层不靠谱是不成立的。
Thumb

小顶 2016-03-30 06:11

淘汰和更新,如果需要让缓存作为主数据源就更新,生成逻辑再复杂也是可以独立的,但确实要保障强一致性,否则问题就大了。时序,如果先清缓存再更新DB,理论上存在两者间新缓存生成,数据不一致的可能,不推荐。
Thumb

yangxiaoxiaopro 2016-03-30 06:33

先淘汰再写数据库也有并发问题吧,就是淘汰完了更新数据库期间另一个读取操作又写了cache…
Thumb

KeepFatAngel 2016-03-30 14:16

采用淘汰缓存的策略还有个好处是在无法保证数据库与缓存事务一致性的情况下保证数据一致性,代价是增加一次缓存未命中。
Thumb

大将军X 2016-03-31 17:12

淘汰缓存和写数据库这两步是否要加锁呢?在并发环境下
用微信扫描
小程序码阅读原文

开发者头条

程序员分享平台