认识达内从这里开始

缓存功能的应用在软件开发和网页开发中是经常会使用的一个功能，而今天我们就通过案例分析来了解一下，缓存功能常用策略的优缺点都有哪些。

一、CacheAside读写策略

CacheAside读写策略也叫缓存旁路读写策略，针对读写的策略分别是：

读流程：

先从缓存中读取，如果有结果则直接返回结束

如果缓存中没有，则读DB并将结果回种缓存，然后返回结束

写流程：

先将将结果写入DB

然后删除缓存中对应的值

实际生产环境中，此种策略的使用也相对比较广泛，可以作为一种参考。这里需要注意一点的是，针对写流程，不能先删除缓存，在更新DB，因为缓存删除后，此时DB还没有更新完时，来了一个get请求，那么缓存就有可能会被种入一个已失效的结果。

二、CacheAside读写策略优缺点对比

优点：

此种策略实现比较简单。

对于缓存和DB的一致性有了一定的保证，其可以解决缓存方案遇到的问题。

缺点：

很显然，每次更新数据，都会先更新DB紧接着就删除缓存，如果读写操作都比较频繁的情况下，势必使得缓存的命中率有所折扣，也就意味着缓存的miss率升高，从而导致在一定程度上削弱了缓存的作用。

针对此种方案的缺点，其实也有一些比较折中的方案可以考虑。比如在更新DB完成后，同样更新缓存，但是在更新缓存的时候增加分布式锁避免;在比如如果业务场景并不是要求强一致性的话，可以将数据写入缓存并增加一个过期时间，这样即使数据不一致也只是一段时间。

对于增加过期时间的这种方式，存在极热key的场景并不是适用的，因为一旦key过期后，在一瞬间大量请求越过缓存，直冲DB，也就造成了缓存穿透的问题，所以CacheAside方案看起来很不错，但是也不是万能的。

三、Write/ReadThrough策略

Write/ReadThrough的缓存策略不同于前两种，该策略需要引入三方缓存同步插件。其读写流程如下：

读流程：

先读缓存，如果缓存命中，则直接返回结果

如果缓存未命中，则依赖三方组件从DB中加载数据到缓存中，然后将获取的结果返回。

写流程：

要更新的数据是否在缓存中存在，若存在则直接将数据写入缓存，之后缓存数据由三方缓存组件将其更新到DB

若缓存中不存在，则直接将结果写入DB，这种称之为写穿透

四、Write/ReadThrough策略优缺点对

优点：

写缓存miss的情况除外，剩余所有操作都只与缓存进行交互，很大程度上避免了缓存与DB一直性的情况

缺点：

写缓存miss时直接与DB交互，会造成请求耗时增加

此种缓存策略引入了三方缓存组件进行辅助，从而增加了系统的复杂度和系统的维护难度

由于需要引入三方组件，而目前很多缓存如Redis原生并不兼容三方组件，所以很难引入

总和上面这些情况对比，目前采用此种缓存读写策略的场景很少，作者到目前还没有见过使用这种缓存策略的场景。

五、WriteBack策略

WriteBack策略是一种操作系统在使用的缓存读写策略，由于其实现比较复杂，所以读者朋友可以做一些了解即可，目前没有在生产环境中实际使用过。

写操作流程如下：

写请求来之后，先判断要写的key在缓存中是否被标记为“脏数据”，如果不是“脏数据”则直接写缓存，然后将其标记为脏数据

如果缓存中标记的是“脏数据”，则直接将其写入DB，然后回种缓存，然后将其标记为“脏数据”

读操作流程如下：

先从缓存中获取数据，若有则直接返回

若缓存中没有，则寻找可用的缓存快，若缓存快被标记为“脏数据”，则将“脏数据”写入DB，然后将缓存的数据标记为“非脏数据”，然后返回

若缓存快中的数据不是“脏数据”，则从DB中加载数据到缓存中，然后将其返回。

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请在707945861群中学习了解。