数据一致性分类

缓存模式

1：cache aside

写请求的四种机制对比

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

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

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

线程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）

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

线程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读请求

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

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

3：Write behind（异步缓存写入）

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

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