Mango Cache缓存管理库TinyLFU源码解析
作者:司司sama
介绍
据官方所述,mango Cache是对Guava Cache基于go的部分实现,同时mangoCache参考了Caffeine以及go-tinylfu.
支持以下缓存管理策略:
- LRU
- Segmented LRU(默认)
- TinyLFU(实验性)
本文将从源码对其进行解析,重点将放在loadingCache(一种可以自定义如何载入新内存的cache)上面.
整体架构
mango Cache的主体功能由localCache结构体(local.go)实现,
type localCache struct { cache cache // 真正存放数据的地方 expireAfterAccess time.Duration //用户自定义的过期以及刷新时间 expireAfterWrite time.Duration refreshAfterWrite time.Duration policyName string //缓存管理策略 onInsertion Func //钩子函数 onRemoval Func loader LoaderFunc //自定义加载和重载函数 reloader Reloader stats StatsCounter //状态管理器 cap int //缓存容量 // 访问时的缓存管理策略 accessQueue policy // 写入时的缓存管理策略,只有在expireAfterWrite或refreshAfterWrite被设置以后才启用 writeQueue policy // 用于processEntries的事件队列 events chan entryEvent // 记录距离上一次写期间发生的读次数,用于判断是否进行清扫 readCount int32 // 用于关闭由localCache创建的协程 closing int32 closeWG sync.WaitGroup }
真正存储数据的结构体是cache(policy.go),所有缓存数据都存储在其中
type cache struct { size int64 // 缓存大小 segs [segmentCount]sync.Map // 分片sync.map, map[key]*entry }
entry是存放一个缓存数据的单元
type entry struct { hash uint64 //key的hash值 accessTime int64 writeTime int64 invalidated int32 //是否有效 loading int32 //是否处于载入中状态 key Key value atomic.Value // 存储的值 // 下面的属性只被缓存管理策略操作,所以不需要原子性的访问 accessList *list.Element //此entry目前所在的访问链表中的位置 writeList *list.Element //此entry目前所在的写入链表中的位置 listID uint8 //此entry目前所在的缓存段(SLRU) }
localCache使用事件队列来管理并发读写事件,事件队列是一个chan,其中流转着entryEvent(即数据以及对应的缓存事件),localCache通过processEntries协程来处理各种读写事件.之后将详细讲解mango Cache是如何进行读写操作的.
localCache的write、access等操作底层是通过操作cache、accessQueue以及writeQueue从而实现的,而localCache还会负责清扫过期数据的工作.
前面提到了mango Cache支持诸如LRU、SLRU以及TinyLFU等缓存管理策略,其在localCache中即为accessQueue以及writeQueue,负责对缓存的淘汰准入等操作.
初始化流程
mango Cache提供了两种cache---普通Cache以及LoadingCache,这两者都是接口,而localCache实现了这两个接口,由于LoadingCache继承了普通Cache,因此本文只讲解LoadingCache.
func NewLoadingCache(loader LoaderFunc, options ...Option) LoadingCache { c := newLocalCache() c.loader = loader for _, opt := range options { opt(c) } c.init() return c }
NewLoadingCache函数先初始化一个LoadingCache,然后根据用户传入的自定义载入函数和一些配置来初始化LoadingCache.配置包括注册插入或者删除时触发的钩子函数以及过期时间等等.然后调用localCache.init.
func (c *localCache) init() { c.accessQueue = newPolicy(c.policyName) c.accessQueue.init(&c.cache, c.cap) if c.expireAfterWrite > 0 || c.refreshAfterWrite > 0 { c.writeQueue = &recencyQueue{} } else { c.writeQueue = discardingQueue{} } c.writeQueue.init(&c.cache, c.cap) c.events = make(chan entryEvent, chanBufSize) c.closeWG.Add(1) go c.processEntries() }
localCache.init会根据用户传入的缓存管理策略名字来初始化accessQueue然后根据是否有写过期和写刷新配置来决定是否初始化写入队列.接着创建事件队列并开启事件处理协程.到此为止,cache启动完成.
读流程
LoadingCache的Get操作可以通过key获取缓存值,其流程为:
先从主缓存中查询entry
若未查询到entry,则记录miss并且调用用户自定义的load方法加载缓存值并返回
若查询到entry,先检查是否过期
- 若过期且没有设置loader则直接向事件处理协程发送eventDelete
- 若过期但设置了loader,则异步更新entry值
若没有过期则更新访问时间并向事件处理协程发送eventAccess然后记录命中
最后返回entry
func (c *localCache) Get(k Key) (Value, error) { en := c.cache.get(k, sum(k)) //计算key的hash并查询该key if en == nil { c.stats.RecordMisses(1) return c.load(k) } // 检查entry是否需要更新 now := currentTime() if c.isExpired(en, now) { if c.loader == nil { //如果没有设置加载器则直接删除该entry c.sendEvent(eventDelete, en) } else { //对于loadingCache,我们不删除这个entry //而是把它暂时留在缓存中,所以用户依旧可以读取到旧的缓存值 c.setEntryAccessTime(en, now) c.refreshAsync(en) } c.stats.RecordMisses(1) } else { c.setEntryAccessTime(en, now) c.sendEvent(eventAccess, en) c.stats.RecordHits(1) } return en.getValue(), nil }
需要注意一下这里的refreshAsync函数:
func (c *localCache) refreshAsync(en *entry) bool { if en.setLoading(true) { // 如果此entry没有在加载 if c.reloader == nil { go c.refresh(en) } else { c.reload(en) } return true } return false }
如果没有用户设置的重载器,就异步执行refresh,refresh函数实际上就是对entry进行加载.
而如果有重载器那么就同步执行用户自定义的reload函数.
写流程
loadingCache的Put操作与Get操作类似,流程如下:
先去主缓存查询key是否存在,若查询到对应的entry,那么直接更新entry
若没有查询到对应的entry,说明其不存在,因此根据key,value初始化一个新entry
如果缓存容量足够,则让主缓存存储该entry,此时会再次检查主存中是否有该entry(解决并发问题)
- 若cen不为空,说明主缓存中已经存在该entry,直接修改该entry即可
- 若cen为空,说明主缓存中还不存在该entry,那么就会在主缓存中存储该entry
最后向事件处理协程发送eventWrite事件
func (c *localCache) Put(k Key, v Value) { h := sum(k) en := c.cache.get(k, h) now := currentTime() if en == nil { en = newEntry(k, v, h) c.setEntryWriteTime(en, now) c.setEntryAccessTime(en, now) // 直接将新value添加进缓存(在缓存容量足够的时候) if c.cap == 0 || c.cache.len() < c.cap { cen := c.cache.getOrSet(en) if cen != nil { cen.setValue(v) c.setEntryWriteTime(cen, now) en = cen } } } else { // 更新entry en.setValue(v) c.setEntryWriteTime(en, now) } c.sendEvent(eventWrite, en) } //当entry在缓存中存在,则返回该entry,否则存储该entry func (c *cache) getOrSet(v *entry) *entry { seg := c.segment(v.hash) en, ok := seg.LoadOrStore(v.key, v) if ok { return en.(*entry) } atomic.AddInt64(&c.size, 1) return nil }
事件处理机制
主流程
mango Cache通过entryEvent chan以及processEntries协程来处理并发读写事务
缓存事件一共四个,分别为写入、访问、删除以及关闭.每个业务协程通过向localCache的events chan发送entryEvent通知事件处理协程,进而实现并发读写.
而processEntries协程内,会不断从events chan内取出entryEvent并执行对应的操作,在write、access以及delete操作后会执行清理工作(具体清扫工作由expireEntries函数执行)
type event uint8 const ( eventWrite event = iota eventAccess eventDelete eventClose ) type entryEvent struct { entry *entry event event } func (c *localCache) processEntries() { defer c.closeWG.Done() for e := range c.events { switch e.event { case eventWrite: //写入事务 c.write(e.entry) c.postWriteCleanup() //清理操作 case eventAccess: //访问事务 c.access(e.entry) c.postReadCleanup() //清理操作 case eventDelete: if e.entry == nil { //InvalidateAll函数中使用 c.removeAll() } else { c.remove(e.entry) //移除单个entry } c.postReadCleanup() //清理操作 case eventClose: if c.reloader != nil { // 停止所有refresh工作 c.reloader.Close() } c.removeAll() return } } }
write
由于事件处理机制对于access、delete和write的操作类似,因此这里只讲解较为复杂的write操作:
首先通过调用底层访问队列以及写入队列的write方法
触发用户自定义的钩子函数
如果write方法返回值不为空,说明有entry被驱逐,
因此需要从写入队列将其删除,同时记录驱逐并触发用户自定义的钩子函数
func (c *localCache) write(en *entry) { ren := c.accessQueue.write(en) c.writeQueue.write(en) if c.onInsertion != nil { c.onInsertion(en.key, en.getValue()) } if ren != nil { //有entry被驱逐出了缓存 c.writeQueue.remove(ren) c.stats.RecordEviction() if c.onRemoval != nil { c.onRemoval(ren.key, ren.getValue()) } } }
后面将详细讲述底层访问队列以及缓存管理是如何实现的.
清理工作
前面讲到过每次进行完write、access以及delete操作后会执行清理工作.具体地,write操作会触发postWriteCleanup而access和delete操作会触发postReadCleanup.
postReadCleanup会根据当前距离上一次写的read操作次数是否达到清理工作阈值来决定是否清理,这个阈值是64,也就是说每隔64次read操作就会触发一次清理工作
而postWriteCleanup将在每一次write操作之后触发
真正的清理工作由expireEntries函数完成,它一次清理工作最多只会清理16个entry避免了对事件处理的长时间阻塞.
func (c *localCache) postReadCleanup() { if atomic.AddInt32(&c.readCount, 1) > drainThreshold { atomic.StoreInt32(&c.readCount, 0) c.expireEntries() } } // 在添加完entry以后再执行 func (c *localCache) postWriteCleanup() { atomic.StoreInt32(&c.readCount, 0) c.expireEntries() } //清理工作函数 func (c *localCache) expireEntries() { remain := drainMax now := currentTime() if c.expireAfterAccess > 0 { expiry := now.Add(-c.expireAfterAccess).UnixNano() c.accessQueue.iterate(func(en *entry) bool { if remain == 0 || en.getAccessTime() >= expiry { // 找到了第一个没有过期的entry或者清理entry数足够了 return false } c.remove(en) c.stats.RecordEviction() remain-- return remain > 0 }) } if remain > 0 && c.expireAfterWrite > 0 { ... } if remain > 0 && c.loader != nil && c.refreshAfterWrite > 0 { ... } }
缓存管理
localCache在初始化过程中也初始化了缓存管理策略,由于localCache的writeQueue默认使用LRU缓存淘汰策略,而accessQueue支持LRU、SLRU以及TinyLFU三种缓存淘汰策略,本节将着重讲解accessQueue.
什么是LRU?
LRU是Least Recently Used的缩写,即最近最少使用.在mango Cache中LRU依靠go SDK自带的List(双向链表)实现,新缓存条目会被插入List头部,如果List内元素达到容量上限则删除List尾部的元素,此元素也正是最近最少使用的元素.LRU可以使得主缓存内的缓存条目永远是最近被访问的,不是最近访问的元素将被淘汰.
如果一个不是经常使用的数据,偶尔或者周期性的被使用,那么该数据会被加到LRU链表头部,而这种不经常使用的数据,放在链表头部,占用了空间;一直等到LRU淘汰完,才会被剔除链表;如果这种数据一次性过多,那么链表数据都是这种无用的数据,从而会导致缓存命中率低下,影响系统性能.
什么是SLRU?
Segmented LRU(SLRU)是一种LRU的改进,主要把在一个时间窗口内命中至少2次的记录和命中1次的单独存放,这样就可以把短期内较频繁的缓存元素区分开来.具体做法上,SLRU包含2个固定尺寸的LRU,一个叫Probation段(A1),一个叫Protection段(A2).新记录总是插入到A1中,当A1的记录被再次访问,就把它移到A2,当A2满了需要驱逐记录时,会把驱逐记录插入到A1中.
在mango Cache的实现中,Protection段与Probation段大小比为4:1.
SLRU是mango Cache的默认缓存管理策略
什么是TinyLFU?
TinyLFU是一种空间利用率很高的新的数据结构,可以在较大访问量的场景下近似的替代LFU的数据统计部分(meta-data),其采用类似布隆过滤器的位计数器来实现对每个key的访问次数的粗略统计.(由于哈希冲突的存在,位计数器的结果将偏大)
对于较为静态的访问分布,各种的缓存管理策略的差异是微不足道的,而对于偏倚较大的负载场景,TinyLFU体现出了较大的优势.即便是使用了TinyLFU准入策略进行优化的LRU也获得了较大的提升.
如果想要详细了解TinyLFU请阅读论文TinyLFU: A Highly Efficient Cache Admission Policy 以及一种简略实现讲解LRU、LFU、TinyLFU缓存算法
mango Cache中的TinyLFU
mango Cache的实现中,实际上是实现了改进版的TinyLFU也就是Window-TinyLFU,这个缓存数据结构也在论文中有讲解,简而言之就是缓存由window Cache、doorKeeper(布隆过滤器)、counter以及SLRU组成.主缓存使用SLRU驱逐策略和TinyLFU准入策略,window Cache仅使用LRU驱逐策略无准入策略.
主缓存中的SLRU策略的A1和A2区域被静态划分开来,80%空间被分配给热点元素(A2),被驱逐者则从20%的非热项(A1)中选取.任何到来的元素总是允许进入window Cache, window Cache的淘汰元素有机会进入主缓存,如果在经过TinyLFU准入策略检验后被主缓存接受,那么该元素将进入主缓存,此时Window-TinyLFU的淘汰者就是主缓存的淘汰者(从A1段选出),否则该元素将被window Cache淘汰.
type tinyLFU struct { filter bloomFilter // doorkeeper counter countMinSketch // 4bit计数器 additions int //目前采样数量 samples int //采样窗口大小 lru lruCache //window Cache slru slruCache //主缓存 }
接下来本文将详细讲述mango Cache中tinyLFU的具体实现
counter
counter是实现TinyLFU的重点,对于访问次数的粗略统计就是通过此数据结构实现的.
const sketchDepth = 4 //hash次数 type countMinSketch struct { counters []uint64 mask uint32 }
可以看到, counter由一个uint64类型的数组和一个mask组成, 因为我们使用的是4次hash的4bit计数器,因此数组的每个元素实际上是4个计数器,可以通过位操作来实现访问.
counter的初始化
func (c *countMinSketch) init(width int) { size := nextPowerOfTwo(uint32(width)) >> 2 //size = (width * 4 * 4) bits / 64 if size < 1 { size = 1 } c.mask = size - 1 if len(c.counters) == int(size) { c.clear() } else { c.counters = make([]uint64, size) } }
我们通过传入的width确定需要的计数器数量(size大小)
counter的使用
counter最关键的操作就是按hash增加计数器值以及根据hash估算该hash的计数器值:
func (c *countMinSketch) add(h uint64) { h1, h2 := uint32(h), uint32(h>>32) for i := uint32(0); i < sketchDepth; i++ { //这里使用折叠法求得hash值 idx, off := c.position(h1 + i*h2) c.inc(idx, (16*i)+off) } } // 根据给定hash值返回对应计数器中最小的那个计数器值 func (c *countMinSketch) estimate(h uint64) uint8 { h1, h2 := uint32(h), uint32(h>>32) var min uint8 = 0xFF for i := uint32(0); i < sketchDepth; i++ { idx, off := c.position(h1 + i*h2) count := c.val(idx, (16*i)+off) if count < min { min = count } } return min }
里面的position、val以及inc函数都是对应的位操作,有兴趣的话可以进一步研究下.
需要注意的是estimate函数用于求给定hash对应计数器中最小计数器的值,这是因为有哈希碰撞的情况,因此计数器的值始终会大于等于真实的访问次数,因此这里采用多次hash取其中最小值的方法来减少误差.
同时,为了保证计数器的时效性,counter实现了新鲜度机制,将在一定条件下触发reset:
//将每个计数器的值减半 func (c *countMinSketch) reset() { for i, v := range c.counters { if v != 0 { c.counters[i] = (v >> 1) & 0x7777777777777777 } } }
lruCache
lruCache是LRU的实现,在mango Cache中是一个链表.
type lruCache struct { cache *cache cap int ls list.List } func (l *lruCache) init(c *cache, cap int) { l.cache = c l.cap = cap l.ls.Init() }
slruCache
slruCache是SLRU的实现,在mango Cache中由两个链表组成.
const ( protectedRatio = 0.8 ) type slruCache struct { cache *cache probationCap int probationLs list.List protectedCap int protectedLs list.List } func (l *slruCache) init(c *cache, cap int) { l.cache = c l.protectedCap = int(float64(cap) * protectedRatio) l.probationCap = cap - l.protectedCap l.probationLs.Init() l.protectedLs.Init() }
slruCache中,值得注意的点是它的写入策略:
func (l *slruCache) write(en *entry) *entry { if en.accessList != nil { // entry已存在,直接修改该entry l.markAccess(en) return nil } // 尝试将新entry加入probation段 cen := l.cache.getOrSet(en) if cen == nil { en.listID = probationSegment //将其加入probation段 en.accessList = l.probationLs.PushFront(en) } else { // 该entry已存在,直接修改它的值 cen.setValue(en.getValue()) cen.setWriteTime(en.getWriteTime()) if cen.accessList == nil { //该entry已载入缓存但是还没有注册到SLRU管理的链表中 cen.listID = probationSegment cen.accessList = l.probationLs.PushFront(cen) } else { l.markAccess(cen) } } // probation段超出容量但list并没有超出容量 if l.probationCap > 0 && l.probationLs.Len() > l.probationCap && l.length() > (l.probationCap+l.protectedCap) { // 移除并返回probation段尾部的entry en = getEntry(l.probationLs.Back()) return l.remove(en) } return nil } //记录访问情况 func (l *slruCache) markAccess(en *entry) { if en.listID == protectedSegment { // entry位于在protected段 l.protectedLs.MoveToFront(en.accessList) return } // 若entry位于probation段,则将其提升至protected段 en.listID = protectedSegment l.probationLs.Remove(en.accessList) en.accessList = l.protectedLs.PushFront(en) if l.protectedCap > 0 && l.protectedLs.Len() > l.protectedCap { // protected段超出容量限制,则淘汰其尾部的entry将其加入probation段 en = getEntry(l.protectedLs.Back()) en.listID = probationSegment l.protectedLs.Remove(en.accessList) en.accessList = l.probationLs.PushFront(en) } }
这样一来,就实现了SLRU的缓存管理策略.
filter
filter是一个布隆过滤器,这里不展开讲解其实现细节,只需要了解布隆过滤器可以通过key的hash来确定这个key是否在filter中,并且其只占用非常小的内存.如果想要详细了解布隆过滤器,可以参考这篇文章:布隆过滤器
type bloomFilter struct { numHashes uint32 // 每个元素使用的hash数量 bitsMask uint32 // 位向量大小 bits []uint64 // 过滤器位向量 } //根据给定的插入元素数量以及假阳性率初始化布隆过滤器 func (f *bloomFilter) init(ins int, fpp float64) { ln2 := math.Log(2.0) factor := -math.Log(fpp) / (ln2 * ln2) numBits := nextPowerOfTwo(uint32(float64(ins) * factor)) if numBits == 0 { numBits = 1 } f.bitsMask = numBits - 1 if ins == 0 { f.numHashes = 1 } else { f.numHashes = uint32(ln2 * float64(numBits) / float64(ins)) } size := int(numBits+63) / 64 if len(f.bits) != size { f.bits = make([]uint64, size) } else { f.reset() } }
TinyLFU的初始化
前面介绍了TinyLFU的各个组件,接下来将详细讲解TinyLFU是如何进行缓存管理的.
const ( //entry所处的缓存段 admissionWindow uint8 = iota probationSegment protectedSegment ) const ( samplesMultiplier = 8 //采样窗口大小乘数 insertionsMultiplier = 2 //doorkeeper大小乘数 countersMultiplier = 1 //计数器大小乘数 falsePositiveProbability = 0.1 //假阳性率 admissionRatio = 0.01 //window Cache占比 ) func (l *tinyLFU) init(c *cache, cap int) { if cap > 0 { // 只在容量有上限时开启doorkeeper l.samples = samplesMultiplier * cap //采样窗口大小 l.filter.init(insertionsMultiplier*cap, falsePositiveProbability) //doorkeeper初始化 l.counter.init(countersMultiplier * cap) //计数器初始化 } lruCap := int(float64(cap) * admissionRatio) l.lru.init(c, lruCap) //window Cache初始化 l.slru.init(c, cap-lruCap) //SLRU主存初始化 }
TinyLFU写入
TinyLFU的写入流程如下
首先写入window Cache
如果window Cache出现被淘汰的candidate,则将从SLRU中选取一个victim(如果SLRU未满,则不会产生victim,此时直接将candidate插入SLRU)
在计数器中查询candidate和victim的访问次数
- 若candidate的访问次数较大,则将其插入SLRU,淘汰victim
- 否则将candidate淘汰
根据此流程,我们可以发现被插入SLRU的entry的访问次数一定是较大的,而我们通过计数器实现了对entry访问次数的保存,这样就结合了LRU以及LFU的优点并且没有占用过多的内存,这正是TinyLFU最大的优势所在.
func (l *tinyLFU) write(en *entry) *entry { if l.lru.cap <= 0 { //若容量无限,则直接对SLRU写入 return l.slru.write(en) } l.increase(en.hash) //entry访问次数+1 candidate := l.lru.write(en) //window Cache中被淘汰的entry if candidate == nil { return nil } victim := l.slru.victim() //SLRU中下一个将被淘汰的entry if victim == nil { return l.slru.write(candidate) } candidateFreq := l.estimate(candidate.hash) victimFreq := l.estimate(victim.hash) if candidateFreq > victimFreq { return l.slru.write(candidate) } return candidate }
TinyLFU访问
TinyLFU的访问很简单,只是根据entry所在的缓存段分别调用对应的access函数实现访问
func (l *tinyLFU) access(en *entry) { l.increase(en.hash) if en.listID == admissionWindow { l.lru.access(en) } else { l.slru.access(en) } }
增加entry的访问次数
write函数中通过increase可以对entry的访问次数+1,下面分析一下increase函数:
func (l *tinyLFU) increase(h uint64) { if l.samples <= 0 { return } l.additions++ if l.additions >= l.samples { l.filter.reset() l.counter.reset() l.additions = 0 } if l.filter.put(h) { l.counter.add(h) } }
这里会判断已采样数量是否超出采样窗口,若超出了则会重置doorkeeper和计数器.如果entry在doorkeeper中存在,那么filter.put(h)将返回true,此时会调用counter.add(h)来增加entry的访问次数.
估计entry访问次数
write函数中通过estimate可以查询entry的访问次数,下面分析一下estimate函数:
func (l *tinyLFU) estimate(h uint64) uint8 { freq := l.counter.estimate(h) if l.filter.contains(h) { freq++ } return freq }
已经在前面的章节中介绍过counter.estimate(),其根据hash值返回对应元素的计数器中最小的值以减少哈希碰撞的影响.这里需要注意的是l.filter.contains(h),它将在doorkeeper中查找该hash值是否存在,若存在需要将估计值+1(因为doorkeeper中的值也算访问次数)
总结
Mango Cache中还有统计模块来记录缓存的各方面运行状态(命中率,缓存驱逐等等),由于不是核心内容,因此就不在本文进行赘述了.
Mango Cache最值得学习的点就是事件处理机制和TinyLFU缓存管理策略,希望读者可以好好体会在并发状态下,如何实现安全且高效的缓存操作并借助TinyLFU实现较高的缓存命中率.
以上就是Mango Cache缓存管理库TinyLFU源码解析的详细内容,更多关于Mango Cache TinyLFU的资料请关注脚本之家其它相关文章!