前言

Hello，everybody，我是asong，上一篇文章咱们一起聊一聊了面试中几个常见的缓存问题，明天我仍然聊一聊缓存，不过明天咱们聊的不是面试了，咱们一起来看一看咱们在零碎中缓存更新的设计，因本人教训无限，所以这些缓存设计来源于网上，我只是在这里总结一下，有什么不对的欢送指出～～～????。

缓存预热 To solve 缓存冷启动

在上一篇文章中[常见面试题之缓存雪崩、缓存穿透、缓存击穿]，遗记讲了一个概念——缓存预热，所以在这篇文章补充一下，开一个好头，预热嘛～～～。

什么是缓存预热呢？咱们都晓得平时在跑步前都要热身，能够预防肌肉拉伤等一系例的益处。所以缓存预热具备同样的情理，咱们的新零碎上线后，咱们能够将相干的缓存数据间接加载到缓存零碎。这样能够防止在用户申请的时候，先去查询数据库，而后再将数据缓存的问题。用户能够间接查问当时已被预热的缓存数据。其实缓存预热是为了解决缓存冷启动问题，咱们新零碎上线后，redis集群启动后，没有任何的缓存数据，这就是redis的冷启动。

如上图所示，如果不进行预热，那么Redis初识状态数据为空，零碎上线初期，对于高并发的流量，都会拜访到数据库中，对数据库造成流量的压力。

如何解决

当初咱们曾经晓得会有缓存预热这个问题，那么就要想一下对策咯。能够剖析出以下两点：

  • 须要统计拜访频度较高的热点数据
  • 应用LRU数据删除策略，构建数据留存队列

所以咱们能够设计一个如下计划：

  • 首先，通过 nginx + lua 的形式，把拜访流量数据上报到 Kafka，也能够是其它的 mq 队列。
  • 而后应用实时计算框架(如 storm 、spark streaming、flume)从 kafka 中生产拜访流量数据，实时计算出拜访频率高的数据，这里统计进去的可能只会有编号信息，如商品编号或博客编号等。
  • 最初，依据编号从 mysql 数据库中查问出具体的信息，写入 redis，开始提供服务。

缓存更新的几种设计

1. 先删除缓存，在更新数据库

尽管这是一种错误方法，然而这种设计也是属于缓存更新的一种办法，所以大家还是要晓得为什么不能够这么做。还是那句话：知其所以然嘛。

这种办法就是在更新数据库时，先删除缓存，而后在更新数据库，而后续的操作会把数据在装载到缓存中，这种逻辑在并发时就会先脏数据，看如下图：

咱们解释一下上图的操作，两个并发操作，一个是更新操作，另一个是查问操作，更新操作删除缓存后，查问操作没有命中缓存，先把老数据读出来后放到缓存中，而后更新操作更新了数据库。于是，在缓存中的数据还是老的数据，导致缓存中的数据是脏的，而且还始终这样脏上来了。所以这个设计是谬误的，不倡议应用。

2. Cache aside

这是咱们最罕用的一种设计模式，其逻辑如下：

  • 查问：程序先从cache中获取数据，有数据间接返回，没有失去，则去数据库中取数据，胜利后更新到缓存中。
  • 更新：先把数据存到数据库中，胜利后，再让缓存生效。

这种设计正好能解决上文呈现脏数据的问题。咱们来理一下，一个是查问操作，一个是更新操作的并发，没有了删除cache数据的操作了，而是先更新了数据库中的数据，此时，缓存仍旧无效，所以，并发的查问操作拿的是没有更新的数据，然而，更新操作马上让缓存的生效了，后续的查问操作再把数据从数据库中拉进去。而不会像文章结尾的那个逻辑产生的问题，后续的查问操作始终都在取老的数据。

那么是不是这种设计就不会存在并发问题了呢？不是的，比方，一个是读操作，然而没有命中缓存，而后就到数据库中取数据，此时来了一个写操作，写完数据库后，让缓存生效，而后，之前的那个读操作再把老的数据放进去，所以，会造成脏数据。但，这个case实践上会呈现，不过，实际上呈现的概率可能非常低，因为这个条件须要产生在读缓存时缓存生效，而且并发着有一个写操作。而实际上数据库的写操作会比读操作慢得多，而且还要锁表，而读操作必须在写操作前进入数据库操作，而又要晚于写操作更新缓存，所有的这些条件都具备的概率根本并不大。

咱们能够为缓存设置上过期工夫，这样能够无效解决这个问题。

3. Read/Write Through

这个模式其实就是将 缓存服务 作为次要的存储，利用的所有读写申请都是间接与缓存服务打交道，而不论最初端的数据库了，数据库的数据由缓存服务来保护和更新。不过缓存中数据变更的时候是同步去更新数据库的，在利用的眼中只有缓存服务。
流程如下：

  • Read Through

Read Through 套路就是在查问操作中更新缓存，也就是说，当缓存生效的时候（过期或LRU换出），Cache Aside是由调用方负责把数据加载入缓存，而Read Through则用缓存服务本人来加载，从而对利用方是通明的。

  • Write Through

Write Through 套路和Read Through相仿，不过是在更新数据时产生。当有数据更新的时候，如果没有命中缓存，间接更新数据库，而后返回。如果命中了缓存，则更新缓存，而后再由Cache本人更新数据库（这是一个同步操作）

这个模式的特点就是呈现脏数据的概率就比拟低，然而就强依赖缓存了，对缓存服务的稳定性有较大要求，另外，减少新缓存节点时还会有初始状态空数据问题。

4. Write Behind Caching

Write Behind Caching又叫做Write Back，就是在更新数据的时候，只更新缓存，不更新数据库，而缓存会异步地批量更新数据库。这个设计的益处是让数据的I/O操作能够很快，异步的操作还能够合并对同一个数据的屡次操作，性能上是十分可观的。

然而，其带来的问题是，数据不是强一致性的，而且可能会失落。在软件设计上，咱们基本上不可能做出一个没有缺点的设计，就像算法设计中的工夫换空间，空间换工夫一个情理，有时候，强一致性和高性能，高可用和高性性是有抵触的。软件设计素来都是取舍Trade-Off。另外，Write Back实现逻辑比较复杂，因为他须要track有哪数据是被更新了的，须要刷到长久层上。操作系统的write back会在仅当这个cache须要生效的时候，才会被真正长久起来，比方，内存不够了，或是过程退出了等状况，这又叫lazy write。

这个模式的特点就是速度很快，效率会十分高，然而数据的一致性比拟差，还可能会有数据的失落状况，实现逻辑也较为简单。

总结

下面讲的这几种缓存更新设计，都是一些前人应用的总结，这些设计也不是完满的，这个世界上没有完满的设计，所以咱们的设计多多少少会有问题，比方咱们没有思考缓存（Cache）和长久层（Repository）的整体事务的问题。比方，更新Cache胜利，更新数据库失败了怎么吗？或是反过来。对于这个事，如果你须要强一致性，就要好好思考怎么解决这个问题。在软件开发或设计中，我十分倡议在之前先去参考一下已有的设计和思路，看看相应的guideline，best practice或design pattern，吃透了已有的这些货色，再决定是否要从新创造轮子。千万不要似是而非地，想当然的做软件设计。

好啦，这一篇文章到这里就完结了，心愿对你们有用，又不对的中央欢送指出，可增加我的golang交换群，咱们一起学习交换。

结尾给大家发一个小福利吧，最近我在看[微服务架构设计模式]这一本书，讲的很好，本人也收集了一本PDF，有须要的小伙能够到自行下载。获取形式：关注公众号：[Golang梦工厂]，后盾回复：[微服务]，即可获取。

我翻译了一份GIN中文文档，会定期进行保护，有须要的小伙伴后盾回复[gin]即可下载。

golangvx

举荐往期文章：

  • 手把手教姐姐写音讯队列
  • 常见面试题之缓存雪崩、缓存穿透、缓存击穿
  • 详解Context包，看这一篇就够了！！！
  • go-ElasticSearch入门看这一篇就够了(一)
  • 面试官：go中for-range应用过吗？这几个问题你能解释一下起因吗
  • 学会wire依赖注入、cron定时工作其实就这么简略！
  • 据说你还不会jwt和swagger-饭我都不吃了带着实际我的项目我就来了
  • 把握这些Go语言个性，你的程度将进步N个品位(二)
  • go实现多人聊天室，在这里你想聊什么都能够的啦！！！
  • grpc实际-学会grpc就是这么简略
  • go规范库rpc实际
  • 2020最新Gin框架中文文档 asong又捡起来了英语，用心翻译
  • 基于gin的几种热加载形式