缓存与数据库的一致性保证

Question

如题所述

Answer 1

数据一致性分类

缓存模式1：cacheaside

写请求的四种机制对比

重点问题：旁路缓存模型写请求发生时为何选用先更新数据库再删除缓存机制？

写请求共有四种机制可选，如下：

机制一：先更新缓存，再更新数据库

线程A更新20，线程B更新10

1：线程A更新缓存

2：线程B更新缓存

3：线程B更新数据库

4：线程A更新数据库

影响：造成数据不一致（db为20，cache为10）

机制二：先更新数据库，再更新缓存

线程A更新20，线程B更新10

1：线程A更新数据库

2：线程B更新数据库

3：线程B更新缓存

4：线程A更新缓存

影响：造成数据不一致（db为10，cache为20）

机制三：先删除缓存，再更新数据库

线程A更新20，旧数据是10

1：线程A删除缓存

2：线程B无命中缓存

3：线程B查询数据库

4：线程B更新缓存

5：线程A更新数据库

影响：造成数据不一致（db为20，cache为10）

机制四：先更新数据库，再删除缓存(cacheaside写机制)

线程A更新20，旧数据是10

1：线程B未命中缓存

2：线程B查询数据库

3：线程A更新数据库

4：线程A删除缓存

5：线程B更新数据库影响：造成数据不一致（db为20，cache为10），但是这种机制在四种机制里发生的情况最低（猜的）

达到最终一致性的2个方法方法一：缓存设置过期时间

业务允许少量数据某段时间内数据不一致

方法二：缓存延时双删

删除缓存失败，引入删除重试机制方法一：借助消息队列，业务代码入侵

原理：将删除失败的key放入消息队列中，再消费消息，重试删除缓存操作

缺点：造成许多业务代码入侵

方法二：借助binlog机制

原理：扫描binlog日志，通过ACK机制确认是否删除缓存

2：Read-Through/Write-Through

Read-Through读请求

多了个CacheProvider，让应用程序代码简洁Write-Through写请求

注意：更新缓存和更新数据库是同步的

3：Writebehind（异步缓存写入）

先更新缓存，再批量异步地更新数据库

优缺点：性能高，适用于频繁写的业务，但不适用于一致性要求高的业务

logo设计

创造品牌价值

¥500元起

APP开发

量身定制，源码交付

¥2000元起

商标注册

一个好品牌从商标开始

¥1480元起

公司注册

注册公司全程代办

¥0元起

查

看

更

多

官方电话官方服务
官方网站八戒财税知识产权八戒服务商企业需求数字市场