极客时间-读多写少型缓存设计-Toy模板网

这篇具有很好参考价值的文章主要介绍了极客时间-读多写少型缓存设计。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

背景

内容是极客时间-徐长龙老师的高并发系统实战课的个人学习笔记，欢迎大家学习！https://time.geekbang.org/column/article/596644

总览内容如下：
极客时间-读多写少型缓存设计,极客时间,缓存,java,redis

缓存性价比

一般来说，只有热点数据放到缓存才更有价值

数据量
查询频率
命中率

临时缓存

把目标放到会被高频查询的信息，也就是用户信息，在用户信息第一次被使用的时候，同时将数据放到缓存中，短期内如果再次有类似的查询酒可以快速从缓存中获取，伪代码如下。

userInfo, err := Redis.Get("user_info_9527")
if err != nil {
	return nil, err
}

if userInfo != nil {
	return userInfo, nil
}

userInfo, err := userInfoModel.GetUserInfoById(9527)
if err != nil {
	//这里的err是数据库链接时的错误，期望是通知获取方系统错误
	return nil, err
}

if userInfo != nil {
	Redis.set("user_info_9527", userinfo, 60)
	return userInfo, nil
}

//可以未找到，放一个空数据进入，短期内不再访问数据库
Redis.set("user_info_9527", "")
return nil, nil

缓存更新不及时问题

临时缓存有TTL，如果60秒内修改了用户的昵称，缓存不会马上更新

单条实体数据缓存刷新

先更新数据库
然后清理缓存，让下次读取时刷新缓存，防止并发修改导致临时数据进入缓存

可以给队列发更新消息让子系统更新，还可以开发中间件把数据操作发给子系统，自行决定更新的数据范围

中间件可以失败重试，保证其可以更新成功
队列形式可以保证并发的执行顺序

问题：但条件批量更新的操作无法知道具体有多少个ID可能有修改（更新操作是基于条件进行的，因此在更新之前无法确定有多少个ID可能已经被修改）

解法：先用同样的条件把所有涉及的ID都取出来，然后update，这时用所有相关ID更新具体缓存即可。

关系型和统计型数据缓存刷新

这类数据缓存刷新存在一定难度，核心在于统计是由多条数据计算而成的。很难识别出需要刷新哪些关联缓存

人工维护缓存方式

刷新缓存很多，那么缓存更新会比较慢，并且存在延迟

订阅数据库来找到ID数据变化

maxwell 或 canal，对MySQL的更新进行监控

缺点：复杂的关联关系刷新，仍旧需要通过人工写逻辑来实现

版本号缓存设计

一旦有任何更新，整个表内所有数据缓存一起过期

user_info表设置一个key，更新这个表数据时，直接对key+1，在缓存中也保留version的值。

当业务要读取user_info某个用户的信息的时候，业务会同时获取当前表的version。如果发现缓存数据内的版本和当前表的版本不一致，那么就会更新这条数据。但如果 version 更新很频繁，就会严重降低缓存命中率，所以这种方案适合更新很少的表。

当然，我们还可以对这个表做一个范围拆分，比如按 ID 范围分块拆分出多个 version，通过这样的方式来减少缓存刷新的范围和频率。

识别主要实体ID来刷新缓存

这要保证其他缓存保存的key也是主要实体ID

异步脚本遍历数据库刷新所有相关缓存

这个方式适用于两个系统之间同步数据，能够减少系统间的接口交互；缺点是删除数据后，还需要人工删除对应的缓存，所以更新会有延迟。但如果能配合订阅更新消息广播的话，可以做到准同步

长期热数据缓存

长期缓存要求业务几乎不走数据库，并且服务运转期间所需的数据都要能在缓存中找到，同时还要保证使用期间缓存不丢。

下面伪代码使用了singleflight方式预防临时缓存被大量请求穿透

singleflight实现可以参考我的另一个博客https://editor.csdn.net/md/?articleId=135174867

// 尝试从缓存中直接获取用户信息
userinfo, err := Redis.Get("user_info_9527")
if err != nil {
  return nil, err
}

//缓存命中找到，直接返回用户信息
if userinfo != nil {
  return userinfo, nil
}

//set 检测当前是否是热数据
//之所以没有使用Bloom Filter是因为有概率碰撞不准
//如果key数量超过千个，建议还是用Bloom Filter
//这个判断也可以放在业务逻辑代码中，用配置同步做
isHotKey, err := Redis.SISMEMBER("hot_key", "user_info_9527")
if err != nil {
  return nil, err
}

//如果是热key
if isHotKey {
  //没有找到就认为数据不存在
  //可能是被删除了
  return "", nil
}

//没有命中缓存，并且没被标注是热点，被认为是临时缓存，那么从数据库中获取
//设置更新锁set user_info_9527_lock nx ex 5
//防止多个线程同时并发查询数据库导致数据库压力过大
lock, err := Redis.Set("user_info_9527_lock", "1", "nx", 5)
if !lock {
  //没抢到锁的直接等待1秒 然后再拿一次结果，类似singleflight实现
  //行业常见缓存服务，读并发能力很强，但写并发能力并不好
  //过高的并行刷新会刷沉缓存
  time.sleep( time.second)
  //等1秒后拿数据，这个数据是抢到锁的请求填入的
  //通过这个方式降低数据库压力
  userinfo, err := Redis.Get("user_info_9527")
  if err != nil {
    return nil, err
  }
  return userinfo,nil
}

//拿到锁的查数据库，然后填入缓存
userinfo, err := userInfoModel.GetUserInfoById(9527)
if err != nil {
  return nil, err
}

//查找到用户信息
if userinfo != nil {
  //将用户信息缓存，并设置TTL超时时间让其60秒后失效
  Redis.Set("user_info_9527", userinfo, 60)
  return userinfo, nil
}

// 没有找到，放一个空数据进去，短期内不再问数据库
Redis.Set("user_info_9527", "", 30)
return nil, nil