先操作缓存还是数据库

转载：http://zhuanlan.51cto.com/art/201807/578810.htm

读操作：

• 尝试从缓存get数据，结果没有命中;
• 从数据库获取数据，读从库，读写分离;
• 把数据set到缓存，未来能够命中缓存;

读操作的流程应该没有歧义。

写操作：

写操作，既要操作数据库中的数据，又要操作缓存里的数据。

这里，有两个方案：

• 先操作数据库，再操作缓存;
• 先操作缓存，再操作数据库;

并且，希望保证两个操作的原子性，要么同时成功，要么同时失败。

这演变为一个分布式事务的问题，保证原子性十分困难，很有可能出现一半成功，一半失败，接下来看下，当原子性被破坏的时候，分别会发生什么。

1.先数据库，再缓存

正常情况下：

• 先操作数据库，成功;
• 再操作缓存(delete或者set)，也成功;

但如果这两个动作原子性被破坏：第一步成功，第二步失败，会导致，数据库里是新数据，而缓存里是旧数据，业务无法接受。

画外音：如果第一步就失败，可以返回调用方50X，不会出现数据不一致。

2.先缓存，再数据库

正常情况下：

• 先操作缓存(delete或者set)，成功;
• 再操作数据库，也成功;

画外音：如果第一步就失败，也可以返回调用方50X，不会出现数据不一致。

如果原子性被破坏，会发生什么呢?

这里又分了两种情况：

• 操作缓存使用set
• 操作缓存使用delete

使用set的情况：第一步成功，第二步失败，会导致，缓存里是set后的数据，数据库里是之前的数据，数据不一致，业务无法接受。

并且，一般来说，数据最终以数据库为准，写缓存成功，其实并不算成功。

使用delete的情况：第一步成功，第二步失败，会导致，缓存里没有数据，数据库里是之前的数据，数据没有不一致，对业务无影响。只是下一次读取，会多一次cache miss。

画外音：此时可以返回调用方50X。

最终，先操作缓存，还是先操作数据库?

答：

(1) 读请求，先读缓存，如果没有命中，读数据库，再set回缓存

(2) 写请求

• 先缓存，再数据库      （最终已数据库为准的话，我自己觉得先数据库也是可以的。数据库失败就不更新缓存。）
• 缓存，使用delete，而不是set     （如果对象很大的话，当然删除更快。delete相对来说更好，只不过多了一次cache miss而已。）

先操作缓存还是数据库

原文：https://www.cnblogs.com/fanguangdexiaoyuer/p/9545181.html