关于golang:缓存原理与微服务缓存自动管理

抛开业务谈技术都是在耍流氓。—— Kevin Wan

先从一个陈词滥调的问题开始谈起：咱们的程序是如何运行起来的？

程序存储在 disk 中
程序是运行在 RAM 之中，也就是咱们所说的 main memory
程序的计算逻辑在 CPU 中执行

来看一个最简略的例子：a = a + 1

load x:
x0 = x0 + 1
load x0 -> RAM

下面提到了 3 种存储介质。咱们都晓得，三类的读写速度和老本成反比，所以咱们在克服速度问题上须要引入一个 中间层。这个中间层，须要高速存取的速度，然而老本可承受。于是乎，Cache 被引入

而在计算机系统中，有两种默认缓存：

CPU 外面的末级缓存，即 LLC。缓存内存中的数据
内存中的高速页缓存，即 page cache。缓存磁盘中的数据

引入 Cache 之后，咱们持续来看看操作缓存会产生什么。因为存在存取速度的差别「而且差别很大」，从而在操作数据时，提早或程序失败等都会导致缓存和理论存储层数据不统一。

咱们就以规范的 Cache+DB 来看看经典读写策略和利用场景。

先来思考一种最简略的业务场景，比方用户表：userId: 用户 id, phone: 用户电话 token，avtoar: 用户头像 url，缓存中咱们用 phone 作为 key 存储用户头像。当用户批改头像 url 该如何做？

更新 DB 数据，再更新Cache 数据
更新 DB 数据，再删除 Cache 数据

首先 变更数据库 和 变更缓存 是两个独立的操作，而咱们并没有对操作做任何的并发管制。那么当两个线程并发更新它们的时候，就会因为写入程序的不同造成数据不统一。

所以更好的计划是 2：

更新数据时不更新缓存，而是间接删除缓存
后续的申请发现缓存缺失，回去查问 DB，并将后果 load cache

这个策略就是咱们应用缓存最常见的策略：Cache Aside。这个策略数据以数据库中的数据为准，缓存中的数据是按需加载的，分为读策略和写策略。

然而可见的问题也就呈现了：频繁的读写操作会导致 Cache 重复地替换，缓存命中率升高。当然如果在业务中对命中率有监控报警时，能够思考以下计划：

更新数据时同时更新缓存，然而在更新缓存前加一个 分布式锁。这样同一时间只有一个线程操作缓存，解决了并发问题。同时在后续读申请中时读到最新的缓存，解决了不统一的问题。
更新数据时同时更新缓存，然而给缓存一个较短的 TTL。

当然除了这个策略，在计算机体系还有其余几种经典的缓存策略，它们也有各自实用的应用场景。

先查问写入数据 key 是否击中缓存，如果在 -> 更新缓存，同时缓存组件同步数据至 DB；不存在，则触发 Write Miss。

而个别 Write Miss 有两种形式：

Write Allocate：写时间接调配 Cache line
No-write allocate：写时不写入缓存，间接写入 DB，return

在 Write Through 中，个别采取 No-write allocate。因为其实无论哪种，最终数据都会长久化到 DB 中，省去一步缓存的写入，晋升写性能。而缓存由 Read Through 写入缓存。

这个策略的外围准则：用户只与缓存打交道，由缓存组件和 DB 通信，写入或者读取数据。在一些本地过程缓存组件能够思考这种策略。

置信你也看出上述计划的缺点：写数据时缓存和数据库同步，然而咱们晓得这两块存储介质的速度差几个数量级，对写入性能是有很大影响。那咱们是否异步更新数据库？

Write back 就是在写数据时只更新该 Cache Line 对应的数据，并把该行标记为 Dirty。在读数据时或是在缓存满时换出「缓存替换策略」时，将 Dirty 写入存储。

须要留神的是：在 Write Miss 状况下，采取的是 Write Allocate，即写入存储同时写入缓存，这样咱们在之后的写申请只须要更新缓存。

async purge 此类概念其实存在计算机体系中。Mysql 中刷脏页，实质都是尽可能避免随机写，对立写磁盘机会。

Redis是一个独立的系统软件，和咱们写的业务程序是两个软件。当咱们部署了 Redis 实例后，它只会被动地期待客户端发送申请，而后再进行解决。所以，如果应用程序想要应用 Redis 缓存，咱们就要在程序中减少相应的缓存操作代码。所以咱们也把 Redis 称为 旁路缓存，也就是说：读取缓存、读取数据库和更新缓存的操作都须要在应用程序中来实现。

而作为缓存的 Redis，同样须要面临常见的问题：

缓存的容量究竟无限
上游并发申请冲击
缓存与后端存储数据一致性

一般来说，缓存对于选定的被淘汰数据，会依据其是洁净数据还是脏数据，抉择间接删除还是写回数据库。然而，在 Redis 中，被淘汰数据无论洁净与否都会被删除，所以，这是咱们在应用 Redis 缓存时要特地留神的：当数据批改成为脏数据时，须要在数据库中也把数据批改过去。

所以不论替换策略是什么，脏数据有可能在换入换出中失落。那咱们在产生脏数据就应该删除缓存，而不是更新缓存，所有数据应该以数据库为准。这也很好了解，缓存写入应该交给读申请来实现；写申请尽可能保证数据一致性。

至于替换策略有哪些，网上曾经有很多文章演绎之间的优劣，这里就不再赘述。

并发场景下，可能会有多个线程（协程）同时申请同一份资源，如果每个申请都要走一遍资源的申请过程，除了比拟低效之外，还会对资源服务造成并发的压力。

go-zero 中的 ShardCalls 能够使得同时多个申请只须要发动一次拿后果的调用，其余申请 ” 不劳而获 ”，这种设计无效缩小了资源服务的并发压力，能够无效避免缓存击穿。

对于避免暴增的接口申请对上游服务造成刹时高负载，能够在你的函数包裹：

fn = func() (interface{}, error) {// 业务查问}
data, err = g.Do(apiKey, fn)
// 就取得到 data，之后的办法或者逻辑就能够应用这个 data

其实原理也很简略：

func (g *sharedGroup) Do(key string, fn func() (interface{}, error)) (interface{}, error) {
  // done: false，才会去执行上面的业务逻辑；为 true，间接返回之前获取的 data
  c, done := g.createCall(key)
  if done {return c.val, c.err}
  
  // 执行调用者传入的业务逻辑
  g.makeCall(c, key, fn)
  return c.val, c.err
}

func (g *sharedGroup) createCall(key string) (c *call, done bool) {
  // 只让一个申请进来进行操作
  g.lock.Lock()
  // 如果携带标示一系列申请的 key 在 calls 这个 map 中曾经存在，// 则解锁并同时期待之前申请获取数据，返回
  if c, ok := g.calls[key]; ok {g.lock.Unlock()
    c.wg.Wait()
    return c, true
  }
  
  // 阐明本次申请是首次申请
  c = new(call)
  c.wg.Add(1)
  // 标注申请，因为持有锁，不必放心并发问题
  g.calls[key] = c
  g.lock.Unlock()

  return c, false
}

这种 map+lock 存储并限度申请操作，和 groupcache 中的 singleflight 相似，都是避免缓存击穿的利器

源码地址：sharedcalls.go

这是开发中常见纠结问题：到底是先删除缓存还是先更新存储？

状况一：先删除缓存，再更新存储；

A 删除缓存，更新存储时网络提早

B 读申请，发现缓存缺失，读存储 -> 此时读到旧数据

这样会产生两个问题：

B 读取旧值
B 同时读申请会把旧值写入缓存，导致后续读申请读到旧值

既然是缓存可能是旧值，那就不论删除。有一个并不优雅的解决方案：在写申请更新完存储值当前，sleep() 一小段时间，再进行一次缓存删除操作。

sleep 是为了确保读申请完结，写申请能够删除读申请造成的缓存脏数据，当然也要思考到 redis 主从同步的耗时。不过还是要依据理论业务而定。

这个计划会在第一次删除缓存值后，提早一段时间再次进行删除，被称为：提早双删。

状况二：先更新数据库值，再删除缓存值：

A 删除存储值，然而删除缓存网络提早

B 读申请时，缓存击中，就间接返回旧值

这种状况对业务的影响较小，而绝大多数缓存组件都是采取此种更新程序，满足最终一致性要求。

状况三：新用户注册，间接写入数据库，同时缓存中必定没有。如果程序此时读从库，因为主从提早，导致读取不到用户数据。

这种状况就须要针对 Insert 这种操作：插入新数据入数据库同时写缓存。使得后续读申请能够间接读缓存，同时因为是刚插入的新数据，在一段时间批改的可能性不大。

以上计划在简单的状况或多或少都有潜在问题，须要贴合业务做具体的批改。

下面说了这么多，回到咱们开发角度，如果咱们须要思考这么多问题，显然太麻烦了。所以如何把这些缓存策略和替换策略封装起来，简化开发过程？

明确几点：

将业务逻辑和缓存操作拆散，留给开发这一个写入逻辑的点
缓存操作须要思考流量冲击，缓存策略等问题。。。

咱们从读和写两个角度去聊聊 go-zero 是如何封装。

// res: query result
// cacheKey: redis key
err := m.QueryRow(&res, cacheKey, func(conn sqlx.SqlConn, v interface{}) error {
  querySQL := `select * from your_table where campus_id = ? and student_id = ?`
  return conn.QueryRow(v, querySQL, campusId, studentId)
})

咱们将开发查问业务逻辑用 func(conn sqlx.SqlConn, v interface{}) 封装。用户无需思考缓存写入，只须要传入须要写入的 cacheKey。同时把查问后果 res 返回。

那缓存操作是如何被封装在外部呢？来看看函数外部：

func (c cacheNode) QueryRow(v interface{}, key string, query func(conn sqlx.SqlConn, v interface{}) error) error {cacheVal := func(v interface{}) error {return c.SetCache(key, v)
 }
 // 1. cache hit -> return
  // 2. cache miss -> err
 if err := c.doGetCache(key, v); err != nil {// 2.1 err defalut val {*}
  if err == errPlaceholder {return c.errNotFound} else if err != c.errNotFound {return err}
  // 2.2 cache miss -> query db
    // 2.2.1 query db return err {NotFound} -> return err defalut val「see 2.1」if err = query(c.db, v); err == c.errNotFound {if err = c.setCacheWithNotFound(key); err != nil {logx.Error(err)
   }

   return c.errNotFound
  } else if err != nil {c.stat.IncrementDbFails()
   return err
  }
  // 2.3 query db success -> set val to cache
  if err = cacheVal(v); err != nil {logx.Error(err)
   return err
  }
 }
 // 1.1 cache hit -> IncrementHit
 c.stat.IncrementHit()

 return nil
}

从流程上恰好对应缓存策略中的：Read Through。

源码地址：cachedsql.go

而写申请，应用的就是之前缓存策略中的 Cache Aside -> 先写数据库，再删除缓存。

_, err := m.Exec(func(conn sqlx.SqlConn) (result sql.Result, err error) {execSQL := fmt.Sprintf("update your_table set %s where 1=1", m.table, AuthRows)
  return conn.Exec(execSQL, data.RangeId, data.AuthContentId)
}, keys...)

func (cc CachedConn) Exec(exec ExecFn, keys ...string) (sql.Result, error) {res, err := exec(cc.db)
 if err != nil {return nil, err}

 if err := cc.DelCache(keys...); err != nil {return nil, err}

 return res, nil
}

和 QueryRow 一样，调用者只须要负责业务逻辑，缓存写入和删除对调用通明。

源码地址：cachedsql.go

开篇第一句话：脱离业务将技术都是耍流氓。以上都是在对缓存模式分析，然而理论业务中缓存是否起到应有的减速作用？最直观就是缓存击中率，而如何观测到服务的缓存击中？这就波及到监控。

下图是咱们线上环境的某个服务的缓存记录状况：

还记得下面 QueryRow 中：查问缓存击中，会调用 c.stat.IncrementHit()。其中的 stat 就是作为监控指标，一直在计算击中率和失败率。

源码地址：cachestat.go

在其余的业务场景中：比方首页信息浏览业务中，大量申请不可避免。所以缓存首页的信息在用户体验上尤其重要。然而又不像之前提到的一些繁多的 key，这里可能波及大量音讯，这个时候就须要其余缓存类型退出：

拆分缓存：能够分 音讯 id -> 由 音讯 id 查问音讯，并缓存插入 音讯 list中。
音讯过期：设置音讯过期工夫，做到不占用过长时间缓存。

这里也就是波及缓存的最佳实际：

不容许不过期的缓存「尤为重要」
分布式缓存，易伸缩
主动生成，自带统计

本文从缓存的引入，常见缓存读写策略，如何保证数据的最终一致性，如何封装一个好用的缓存操作层，也展现了线上缓存的状况以及监控。所有下面谈到的这些缓存细节都能够参考 go-zero 源码实现，见 go-zero 源码的 core/stores。

https://github.com/tal-tech/go-zero

欢送应用 go-zero 并 star 激励咱们！????????

我的项目地址：
https://github.com/tal-tech/go-zero

关于golang:缓存原理与微服务缓存自动管理

为什么须要缓存？

缓存读写策略

Cache Aside

Write Through

Write Back

Redis

替换策略

ShardCalls

缓存和存储更新程序

如何设计好用的缓存操作层？

QueryRow

Exec

线上的缓存

总结

我的项目地址

Just My Socks（注册教程内含优惠码）

关于golang:缓存原理与微服务缓存自动管理

为什么须要缓存？

缓存读写策略

Cache Aside

Write Through

Write Back

Redis

替换策略

ShardCalls

缓存和存储更新程序

如何设计好用的缓存操作层？

QueryRow

Exec

线上的缓存

总结

我的项目地址

Just My Socks（注册教程 内含优惠码）

Just My Socks（注册教程内含优惠码）