redis与Mysql的数据一致性
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,miss,读db
②写db,失效cache
③写chache
导致cache中脏数据,但是概率极低,并且一般db中写时间长于读时间,并且写会锁表,读需要在写前进入,并且要晚于写操作更新缓存,所以发生概率极低。
解决方法是 2pc或是paxos协议,代价较大。
所以我们采用的方式是:
写数据只写db
更新数据先更新db,再失效cache
读数据,先读cache,未命中读db,写入cache