缓存更新的套路
看到好些人在写更新缓存数据代码时，先删除缓存，然后再更新数据库，而后续的操作会把数据再装载的缓存中。然而，这个是逻辑是错误的。试想，两个并发操作，一个是更新操作，另一个是查询操作，更新操作删除缓存后，查询操作没有命中缓存，先把老数据读出来后放到缓存中，然后更新操作更新了数据库。于是，在缓存中的数据还是老的数据，导致缓存中的数据是脏的，而且还一直这样脏下去了。
我不知道为什么这么多人用的都是这个逻辑，当我在微博上发了这个贴以后，我发现好些人给了好多非常复杂和诡异的方案，所以，我想写这篇文章说一下几个缓存更新的Design Pattern（让我们多一些套路吧）。
这里，我们先不讨论更新缓存和更新数据这两个事是一个事务的事，或是会有失败的可能，我们先假设更新数据库和更新缓存都可以成功的情况（我们先把成功的代码逻辑先写对）。
更新缓存的的Design Pattern有四种：Cache aside, Read through, Write through, Write behind caching，我们下面一一来看一下这四种Pattern。
(171 人打了分，平均分： 4.54 )
Loading...
很多朋友问我为什么不在微信公众号上写文章。我都没有直接回答，老实说，我也是扭扭捏捏的，才去开了个个人的微信的公众号，而且还只是为了使用微服小程序，和文章的发布通知，我承认现在的阅读都在移动端，而且微信的公众号是国内移动端的文章流量及分享的入口，但是我还是更愿意使用blog这样的方式分享文章，最多也是在blog这边写好文章后，再去微信公众号那边通知一下。这个原因，不是因为我是一个老顽固，有习惯思维，而是，我不觉得微信公众号是一个好的信息传播和交流的平台。
偶然间看到了阿里中间件