redis与Mysql的数据一致性

为了减少db的读压力,加快读速度,系统使用cache做缓存,会引起cache一致性问题。因为db会有事务性导致回滚,而cache无法回滚,会导致脏数据。

一般情况下,我们会在保存数据时,先穿透保存到DB中,再同步数据到redis中。

为了保证存储层对外层透明,我们会把DB与redis操作封装,对上层调用来说完全透明,不关心数据具体如何存储。

例如在我们的实际业务中有如下场景:A表插入一条数据,同步到redis中,B表插入一条数据,同步到redis中。如果B表插入数据失败,事务回滚,A表中数据可以回滚,但是redis无法回滚。会导致redis中有脏数据。

facebook的一篇论文给出如下设计:

查询:先查询cache,miss时查询db,写入cache

写:写db成功后,失效cache

重点说下写:如果写db成功后,写cache,会有事务性和并发性两方面问题。

1.事务性问题:一个事务包含多个db操作,操作一些db成功,写cache成功,操作二写db失败,事务回滚,db数据回滚,cache无法回滚,导致脏数据。

2.并发性问题:两个更新操作并发,如更新名字,并且cache中key以名字为关键字,更新一写db成功,写缓存XXXX_name1成功。更新二写db成功,写缓存XXXX_name2成功。导致cache脏数据。

这里再说一下一般更新操作顺序是失效cache,写db,写cache。会有并发问题。

两个并发操作,更新和读,左边写线程,右边为读线程

①更新操作删除cache

②读操作读cache,miss

③读db,此时是旧数据

④写db,写cache

⑤写cache 导致cache中脏数据。

虽然写db成功后,失效cache也会有并发问题:更新和读并发

①查询cache

②写db,失效cache

③写chache

导致cache中脏数据,但是概率极低,并且一般db中写时间长于读时间,并且写会锁表,读需要在写前进入,并且要晚于写操作更新缓存,所以发生概率极低。

解决方法是 2PC或是Paxos协议,代价较大。

所以我们采用的方式是:

写数据只写db

更新数据先更新db,再失效cache

读数据,先读cache,未命中读db,写入cache

发布了40 篇原创文章 · 获赞 18 · 访问量 3万+
展开阅读全文

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 编程工作室 设计师: CSDN官方博客

分享到微信朋友圈

×

扫一扫,手机浏览