乐趣区

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

jiezi

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

为什么须要缓存？

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

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

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

  1. load x:
  2. x0 = x0 + 1
  3. load x0 -> RAM

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

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

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

缓存读写策略

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

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

Cache Aside

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

  1. 更新 DB 数据，再更新Cache 数据
  2. 更新 DB 数据，再删除 Cache 数据

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

所以更好的计划是 2：

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

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

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

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

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

Write Through

先查问写入数据 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

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

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

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

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

Redis

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

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

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

替换策略

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

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

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

ShardCalls

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

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 是如何封装。

QueryRow

// 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

Exec

而写申请，应用的就是之前缓存策略中的 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，这里可能波及大量音讯，这个时候就须要其余缓存类型退出：

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

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

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

总结

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

我的项目地址

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

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

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

退出移动版