极客时间-读多写少型缓存设计

背景

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

总览内容如下:
极客时间-读多写少型缓存设计_第1张图片

缓存性价比

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

  • 数据量
  • 查询频率
  • 命中率

临时缓存

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

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秒内修改了用户的昵称,缓存不会马上更新

单条实体数据缓存刷新

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

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

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

问题:但条件批量更新的操作无法知道具体有多少个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

查询某个用户信息时:

如果缓存中没有数据,长期缓存会直接返回没有找到,临时缓存则直接走更新流程。

如果数据属于热点key,并且在缓存中找不到的话,就直接返回不存在。

这些热缓存 key,来自于统计一段时间内数据访问流量,计算得出的热点数据。

TTL过期刷新

那长期缓存的更新会异步脚本去定期扫描热缓存列表,通过这个方式来主动推送缓存,同时把 TTL 设置成更长的时间,来保证新的热数据缓存不会过期,同时需要将热度过的key从当前set移除。

在每个业务服务器上部署一个小容量的Redis来保存热点缓存数据

小容量Redis查不到,再去集群中查

问题

使用 Bloom Filter 识别热点 key 时,有时会识别失误,进而导致数据没有找到,那么如何避免这种情况呢?

使用 Bloom Filter 只能添加新 key,不能删除某一个 key,如果想更好地更新维护,有什么其他方式吗?

https://github.com/MGunlogson/CuckooFilter4J

总结

极客时间-读多写少型缓存设计_第2张图片

你可能感兴趣的:(极客时间,缓存,java,redis)