网站内容更新策略(高并发场景下，小伙伴们怎么利用缓存的思路如下)

　　网站内容更新策略(高并发场景下，小伙伴们怎么利用缓存的思路如下)

　　目录 前言 先更新数据库，再更新缓存 先更新缓存，再更新数据库 先删除缓存，再更新数据库 先更新数据库，再删除缓存 删除缓存失败，导致读写不一致分离，导致前言不一致

　　缓存经常用在项目中。为了减少与数据库的交互，使用缓存的思路如下：

　　缓存设计理念

　　有没有朋友考虑过缓存更新的问题？小伙伴们肯定会说一定用过。当有数据更新时，只需清除缓存即可。下次访问服务时，新值将设置为缓存。那不行吗？是的，在一般项目中，这样的使用就足够了。那么老谷带大家看看高并发场景会出现哪些问题呢？

　　例如，让我们将产品的库存作为缓存。那么现在我们需要更新缓存中的库存值，具体怎么做呢，我们来看以下场景：

　　先更新数据库，再更新缓存

　　现有问题场景：请求A更新值为99，请求B更新值为98

　　上述过程：

　　1）请求A先发起，更新数据库为99，但还没有来得及更新缓存

2）请求B发起，更新数据库为98，又更新了缓存值为98

3）请求A这时才更新缓存的值为99

　　这样数据库的值为98，而缓存的值为99，值不一致。（不建议）

　　先更新缓存，再更新数据库

　　这个过程和上面很相似，出现的问题也很相似

　　1）请求A先更新缓存为99，但还没有来得及更新数据库

2）请求B更新缓存为98，又更新了数据库为98

3）请求A这时更新数据库为99

　　这导致缓存值 98 和数据库 99 导致不一致。（不建议）

　　先删除缓存，再更新数据库

　　现有问题场景：请求A更新值到99，请求B获取值

　　上图中的请求流程：

　　1）请求A更新值，先把缓存中的值删除，但还没有来得及更新数据库

2）此时请求B过来查询此值，发现缓存中不存在，就到数据库中查询

3）请求B在数据库中获取到值，在把值设置到缓存中。

4）请求A这时才更新数据库里面的值为99

　　这导致缓存和数据库不一致，缓存中的值始终是旧数据。（不建议）

　　先更新数据库，再删除缓存

　　这个方案也是老外提出的“Cache-Aside pattern”中更新缓存的策略。这种策略首先确保源头的数据必须是正确的。这种策略是万无一失的吗？有一个非常特殊的场景

　　上图中的流程：缓存在建立过程中突然失效

　　1）请求A发起查询请求，直接到数据库查询到100，但还没有来得及去设置缓存

2）请求B更新值，先更新数据库，在删除缓存

3）请求A这时才设置缓存为100

　　出现这种情况的不一致是因为缓存突然失效了。并且还要保证请求B的更新操作比请求A的查询操作快；这将导致不一致。这种情况发生的可能性很小。一般要求不高的项目可以使用这种方法（推荐）。

　　缓存删除失败，导致不一致

　　在这种先更新数据库再删除缓存的策略中，因为缓存需要被删除，但是如果缓存删除失败，数据库就会与缓存不一致。这个问题该怎么办？我们通常想到的就是使用我们的MQ中间件来实现。

　　在上图所示的流程中，如果缓存删除失败，则将消息发送到消息中间件，进入消息队列。可能有的朋友会问，如果消息传递失败了怎么办？我们可以使用消息中间件的机制来保证 100% 的消息传递（稍后会详细介绍）。这样可以确保即使删除消息失败，我们也会重试。

　　但是这个方案有个问题，就是和我们应用服务的业务代码耦合度比较强。代码业务不清楚。

　　那么我们有没有其他不侵犯业务的计划呢？

　　上图其实使用了mysql的底层机制，binlog日志删除缓存，这样就不需要和业务关联了，删除缓存服务是独立的。我们可以使用阿里巴巴的开源运河来操作。

　　读写分离，导致不一致

　　这种先更新数据库再删除缓存的策略有问题吗？我们再来看另外一个场景，数据库读写分离的场景。一般大中型项目都会使用数据库的读写分离。写入请求在一个存储库中，而读取请求在另一个存储库中。读写分离的一个问题是库之间会因为数据同步而产生数据延迟。

　　那我们再看上面的场景流程，会有问题，因为更新数据的请求B在一个库上，而请求A读取数据的又是另一个库。

　　1）请求B更新值99，删除缓存

2）请求A查询值100（读库数据还没有同步），在更新到缓存中（值为100）

　　这会导致不一致。这种情况是经常发生的，不是小概率事件。那么我们该如何处理呢？老顾下次再介绍。

　　总结：不一致的全部原因是无法确定高并发下每个请求执行的顺序，不知道哪个请求先执行，哪个后执行。

　　-结尾-

　　如果有收获，请帮忙转发，您的鼓励是作者最大的动力，谢谢！