W-TinyLFU 算法实现

最新推荐文章于 2024-11-11 13:55:39 发布
最新推荐文章于 2024-11-11 13:55:39 发布
阅读量1.3k 收藏 21
点赞数 24
分类专栏： 系统设计 文章标签： 算法 golang 缓存
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_40080842/article/details/136320080
版权

前言

不同于常见的 LRU 或 LFU，Window TinyLFU 是一种非常高效的缓存设计方案。先来看下 LRU 和 LFU 算法的缺点：

LFU 缺点：

  • 需要为每个记录项维护频率信息，这将消耗大量的内存空间
  • 可能存在旧数据长期不被淘汰（一开始频繁访问该数据，后来不访问了，也不被淘汰占用缓存）

LRU 缺点：

  • 不能反馈访问频率，对热点数据的命中率不如 LFU

W-TinyLFU 综合了两者的长处：高命令率、低内存占用。

参考链接：

W-TinyLFU 的基础 TinyLFU

TinyLFU 是一种空间利用率很高的数据结构，可以在较大访问量的场景下近似的替代 LFU 的频率统计信息。

它的原理与 BloomFilter 类似，把多个 bit 位看作一个整体，用来统计一个 key 的使用频率，TinyLFU 中的 key 通过多次不同的 hash 计算映射到多个 bit 组。在读取时，取映射的所有值中的最小的值作为 key 的使用频率。

在 Caffeine 中，维护了一个 4-bit CountMinSketch 来记录 key 的使用频率，这意味着 key 最大使用频率为 15。

为了可以移除旧事件，TinyLFU 还采用一种衰减机制，借助 reset 操作：每次 get 数据时都会给计数器加上 1，当计数器到达一个尺寸 W 时，把所有记录的 Sketch 数值都除以 2。

W-TinyLFU 的窗口设计

然而在对同一对象的「稀疏突发」的场景下，TinyLFU 会出现问题。在这种情况下，突发的 key 无法建立足够的频率以保存在缓存中，从而导致不断的 cache miss。Caffeine 通过设计 W-TinyLFU 的策略（包含两个缓存区域）解决了这个问题。

主缓存（main cache）使用 SLRU 逐出策略和 TinyLFU 准入策略（TinyLFU 的准入和淘汰策略是：新增一个元素时，判断使用该元素替换一个旧元素，是否可以提升缓存命中率），而窗口缓存（window cache）采用 LRU 逐出策略而没有任何准入策略。

主缓存根据 SLRU 策略静态划分为 A1 和 A2 两个区域，80% 的空间分配给热门项目（A2），并从 20% 非热门项目中挑选 victim。所有请求的 key 都会被允许进入窗口缓存，而窗口缓存的 victim 则有机会进入主缓存（主缓存没满直接进入；满了的话，比较窗口缓存的 victim 和非热门项目的 victim 的出现频率，留下较高的内个）。

窗口缓存的大小初始为总缓存大小的 1%，主缓存的大小为 99%。

W-TinyLFU 方案如下所示：

W-TinyLFU

具体实现

LRU

以下是代码实现，只有重要部分：

这就是传统的 LRU，需要注意的是当满了再 add 时，没有直接将链表末尾元素删除，再将新元素添加到链表头部，而是采用了交换的方式，减少了内存的申请次数。

type windowLRU struct {
	data map[uint64]*list.Element // key 到相应元素的映射
	cap  int                      // lru 容量
	list *list.List
}

type storeItem struct {
	stage    int
	key      uint64
	value    interface{}
}

// 向窗口 LRU 添加数据
func (lru *windowLRU) add(newitem storeItem) (eitem storeItem, evicted bool) {
	// 没满直接插入
	if lru.list.Len() < lru.cap {
		lru.data[newitem.key] = lru.list.PushFront(&newitem)
		return storeItem{}, false
	}

	// 满了的话需要淘汰链表最后一个
	evictItem := lru.list.Back()
	item := evictItem.Value.(*storeItem)

	// 在哈希表中删除淘汰的元素
	delete(lru.data, item.key)
	// 通过交换，链表最后一个元素内容变为要插入的 newitem
	eitem, *item = *item, newitem

	lru.data[item.key] = evictItem
	lru.list.MoveToFront(evictItem)
	return eitem, true
}

func (lru *windowLRU) get(v *list.Element) {
	lru.list.MoveToFront(v)
}

SLRU

以下是代码实现，只有重要部分：

这是一个分段 LRU 实现，添加元素时先添加到非热门区域，当被 get 时再提升到热门区域。

type segmentedLRU struct {
	data                      map[uint64]*list.Element
	stageColdCap, stageHotCap int
	stageCold, stageHot       *list.List
}

const (
	STAGE_COLD = iota
	STAGE_HOT
	STAGE_WINDOW
)

func (slru *segmentedLRU) add(newitem storeItem) {
	// 默认插入到非热门区域
	newitem.stage = STAGE_COLD

	// 主缓存还没满，直接插入
	if slru.stageCold.Len() < slru.stageColdCap || slru.Len() < slru.stageColdCap+slru.stageHotCap {
		slru.data[newitem.key] = slru.stageCold.PushFront(&newitem)
		return
	}

	// 满了的话需要淘汰非热门链表的最后一个
	e := slru.stageCold.Back()
	item := e.Value.(*storeItem)
	// 在哈希表中删除淘汰的元素
	delete(slru.data, item.key)
	// 直接覆盖链表中的元素
	*item = newitem

	slru.data[item.key] = e
	slru.stageCold.MoveToFront(e)
}

func (slru *segmentedLRU) get(v *list.Element) {
	item := v.Value.(*storeItem)

	// 已经在热门区域了，提到链表头部即可
	if item.stage == STAGE_HOT {
		slru.stageHot.MoveToFront(v)
		return
	}

	// 不在热门区域，但热门区域还有空间
	if slru.stageHot.Len() < slru.stageHotCap {
		slru.stageCold.Remove(v)
		item.stage = STAGE_HOT
		slru.data[item.key] = slru.stageHot.PushFront(item)
		return
	}

	// 此时，既不在热门区域，热门区域也没空间了
	// 需要将热门链表最后一个下放到非热门区域
	back := slru.stageHot.Back()
	bitem := back.Value.(*storeItem)

	*bitem, *item = *item, *bitem

	bitem.stage = STAGE_HOT
	item.stage = STAGE_COLD

	slru.data[item.key] = v
	slru.data[bitem.key] = back

	slru.stageCold.MoveToFront(v)
	slru.stageHot.MoveToFront(back)
}

// 获取将淘汰的元素
func (slru *segmentedLRU) victim() *storeItem {
	if slru.Len() < slru.stageColdCap+slru.stageHotCap {
		return nil
	}

	v := slru.stageCold.Back()
	return v.Value.(*storeItem)
}

Count-Min Sketch

以下是代码实现，只有重要部分：

const (
	cmWidth = 4
)

type cmSketch struct {
	rows [cmWidth]cmRow
	seed [cmWidth]uint64
	mask uint64
}

func newCmSketch(numCounters int64) *cmSketch {
    // next2Power 获取最接近 numCounters 的 2 的幂
	numCounters = next2Power(numCounters)
	sketch := &cmSketch{mask: uint64(numCounters - 1)}
	source := rand.New(rand.NewSource(time.Now().UnixNano()))

	for i := 0; i < cmWidth; i++ {
		sketch.seed[i] = source.Uint64()
		sketch.rows[i] = newCmRow(numCounters)
	}
	return sketch
}

func (s *cmSketch) Increment(hashed uint64) {
	for i := range s.rows {
		s.rows[i].increment((hashed ^ s.seed[i]) & s.mask)
	}
}

// 获取出现次数近似值
func (s *cmSketch) Estimate(hashed uint64) int64 {
	min := byte(255)
	for i := range s.rows {
		val := s.rows[i].get((hashed ^ s.seed[i]) & s.mask)
		if val < min {
			min = val
		}
	}
	return int64(min)
}

func (s *cmSketch) Reset() {
	for _, r := range s.rows {
		r.reset()
	}
}

func (s *cmSketch) Clear() {
	for _, r := range s.rows {
		r.clear()
	}
}

type cmRow []byte

// 为每个计数分配 4 位
func newCmRow(numCounters int64) cmRow {
	return make(cmRow, numCounters/2)
}

// 获取指定位置计数
func (r cmRow) get(n uint64) byte {
	// n/2 定位到相应字节
	// (n & 1) * 4 奇数为 4 偶数为 0
	return r[n/2] >> ((n & 1) * 4) & 0x0f
}

// 增加指定位置计数
func (r cmRow) increment(n uint64) {
	i := n / 2
	s := (n & 1) * 4
	v := (r[i] >> s) & 0x0f
	if v < 15 {
		r[i] += 1 << s
	}
}

// 减少为原来一半
func (r cmRow) reset() {
	for i := range r {
		r[i] = (r[i] >> 1) & 0x77
	}
}

// 全部清空
func (r cmRow) clear() {
	for i := range r {
		r[i] = 0
	}
}

Cache

以下是代码实现，只有重要部分：

type Cache struct {
	lru       *windowLRU
	slru      *segmentedLRU
	c         *cmSketch
	t         int32 // 计数器
	threshold int32 // 用来记录临界值，当计数器等于临界值时调用 reset
	data      map[uint64]*list.Element
}

func NewCache(size int) *Cache {
	const lruPct = 1
	lruSz := (lruPct * size) / 100
	slruSz := int(float64(size) * ((100 - lruPct) / 100.0))
	slruO := int(0.2 * float64(slruSz))
	data := make(map[uint64]*list.Element, size)

	return &Cache{
		lru:  newWindowLRU(lruSz, data),
		slru: newSLRU(data, slruO, slruSz-slruO),
		c:    newCmSketch(int64(size)),
		data: data,
	}
}

func (c *Cache) set(key, value interface{}) bool {
	keyHash := c.keyToHash(key)
	i := storeItem{
		stage:    STAGE_COLD,
		key:      keyHash,
		value:    value,
	}

	// 先向窗口 LRU 中插入
	eitem, evicted := c.lru.add(i)
	// 没有数据被淘汰，插入完成
	if !evicted {
		return true
	}
	// 有数据被淘汰，看主缓存中是否有数据被淘汰
	victim := c.slru.victim()
	// 没有的话，直接插入主缓存
	if victim == nil {
		c.slru.add(eitem)
		return true
	}

	// 此时说明主缓存满了，也有数据被淘汰
	// 比较窗口 lru 和 slru 淘汰的数据的频率，保留频率多的
	vcount := c.c.Estimate(victim.key)
	ocount := c.c.Estimate(eitem.key)

	if ocount < vcount {
		return true
	}

	c.slru.add(eitem)
	return true
}

func (c *Cache) get(key interface{}) (interface{}, bool) {
	c.t++
	// 计数器到达临界时后，调用 Reset()
	if c.t == c.threshold {
		c.c.Reset()
		c.t = 0
	}

	keyHash := c.keyToHash(key)
	val, _ := c.data[keyHash]
	item := val.Value.(*storeItem)
	c.c.Increment(item.key)
	v := item.value

    // 调用相应部分的 get，提到链表的头部
	if item.stage == STAGE_WINDOW {
		c.lru.get(val)
	} else {
		c.slru.get(val)
	}
	return v, true
}
PHP实现W-TinyLFU算法（附完整源码）
希望我的博客，能帮上你解决学习中工作中所遇到的问题
04-26 38
PHP实现W-TinyLFU算法（附完整源码）
PHP实现LFU算法（附完整源码）
希望我的博客，能帮上你解决学习中工作中所遇到的问题
04-26 39
PHP实现LFU算法（附完整源码）
阅读 redis 源码，学习缓存淘汰算法 W-TinyLFU
jinggege_795的博客
11-08 4949
所有 IT 从业者都接触过缓存，一定了解基本工作原理，业界流行一句话：缓存就是万金油，哪里有问题哪里抹一下。那他的本质是什么呢？ 上图代表从 cpu 到底层硬盘不同层次，不同模块的运行速度，上层多加一层 cache, 就能解决下层的速度慢的问题，这里的慢是指两点：IO 慢和 cpu 重复计算缓存中间结果 但是 cache 受限于成本，cache size 一般都是固定的，所以数据需要淘汰，由此引出一系列其它问题：缓存一致性、击穿、雪崩、污染等等，本文通过阅读 redis 源码，学习主流淘汰算..
w-tinyLFU
qq_25622107的博客
08-23 3971
缓存设计是个基础架构领域里的重要话题，本号之前也有谈论过相关话题，点击原文可以看之前的介绍。   近日，HighScalability网站刊登了一篇文章，由前Google工程师发明的W-TinyLFU——一种现代的缓存。那么，什么缓存设计能够被称作是“现代”的呢？   当数据的访问模式不随时间变化的时候，LFU的策略能够带来最佳的缓存命中率。然而LFU有两个缺点：首先，它需要给每个记录项维...
TinyLFU缓存准入策略项目常见问题解决方案
最新发布
gitblog_00115的博客
11-11 326
TinyLFU缓存准入策略项目常见问题解决方案 go-tinylfu TinyLFU cache admission policy 项目地址: https://gitcode.com/gh_mirrors/go/go-tinylf...
caffeine框架 W-TinyLFU算法详解
全场梦游c的博客
10-19 2237
最近刚产生的缓存项进入Window区，不会被淘汰；访问频率高的缓存项进入Protected区，也不会淘汰；通过这种机制，平衡了访问频率和访问时间新鲜程度两个维度因素，尽量将新鲜的和访问频率高的缓存项保留在缓存中。
caffeine---window-TinyLFU算法
zouke314的博客
09-23 686
解决的问题： 1、对于突发流量，需要有比较友好的机制应对，不能将新进来的数据淘汰 2、对于访问频次不高的数据需要淘汰 3、对于早期访问频次高，而后来几乎不访问的高频次无效数据，需要淘汰 4、对于内存占用尽量减小 tinyLFU的体系结构如下图所示，当有新数据插入时，缓存淘汰策略选定一个候选淘汰数据项，tinyLFU来决定是否用新的数据项来代替候选被淘汰数据项，来增加缓存命中率。 因此，tinyLFU需要维护相当长的一段历史时期内数据项访问的频率统计信息。维护这一份数据的代价是相当昂贵的，所以
现代的缓存设计方案：Window-TinyLFU
凌桓丶的博客
03-27 2512
现代的缓存设计方案：Window-TinyLFu
一篇学会Caffeine W-TinyLFU源码分析
xxsiyao的博客
07-14 785
Caffeine使用一个ConcurrencyHashMap来保存所有数据，那它的过期淘汰策略采用什么方式与数据结构呢?其中写过期是使用writeOrderDeque,这个比较简单无需多说，而读过期相对复杂很多，使用W-TinyLFU的结构与算法。【资料获取】 网络上有很多文章介绍W-TinyLFU结构的，大家可以去查一下，这里主要是从源码来分析，总的来说它使用了三个双端队列： accessOrderEdenDeque,accessOrderProbationDeque,accessOrderProte
Caffeine的Window TinyLfu算法分析
snail-jie的博客
06-17 1735
概括 通过put操作将数据放入data属性中（ConcurrentHashMap） 创建AddTask任务，放入(offer)写缓存：writeBuffer 从writeBuffer中获取任务，并执行其run方法,追加记录频率：frequencySketch().increment(key) 往window区写入数据 W-TinyLFU 整体设计 本部分参考了泥瓦匠BYSocket的文章，文章链接：https://jishuin.proginn.com/p/763bfbd358a0 判断一个缓存的好坏
【Caffeine缓存】Caffeine缓存淘汰算法Window-TinyLFU详解
Sihang_Xie的博客
02-07 3692
Caffeine的缓存淘汰策略是什么？Window-TinyLFU算法的原理是什么？是如何工作的？看完本文，相信你会得到答案。
缓存Caffeine之W-TinyLFU淘汰策略
sinat_14913533的博客
01-19 2702
我们常见的缓存是基于内存的缓存，但是单机的内存是有限的，不能让缓存数据撑爆内存，所有需要缓存淘汰机制。中大概说明了LRU的缓存淘汰机制，以及基于LRU的著名实现guava cache。除了LRU淘汰策略外，其是常见的还有FIFO以及LFU，只是说目前用的最多的是LRU。
缓存算法-FIFO/LRU/LFU/W-TinyLFU
l_dongyang的博客
09-19 4401
一、概况 《Caffeine入门使用》一文中介绍了当下性能比较好且正在流行的缓存组件Caffeine Cache，一个缓存组件是否好用，其中一个重要的指标就是他的缓存命中率，而命中率又和缓存组件本身的缓存数据淘汰算法息息相关的，本文意在讲解一些业界内常见的页面置换算法，以及在详细的介绍下Caffeine Cache的W-TinyLFU算法，以便于更好的理解缓存组件。 二、讲解 2.1 FIFO FIFO（First in First out）先进先出。可以理解为是一种队列的实现 算法：最先进来的数据，被认为
Caffine Cache 在算法上的优点-W-TinyLFU
weixin_42470128的博客
10-02 517
常见的缓存淘汰算法还有FIFO，LFU： FIFO：先进先出，在这种淘汰算法中，先进入缓存的会先被淘汰，会导致命中率很低。 LRU：最近最少使用算法，每次访问数据都会将其放在我们的队尾，如果需要淘汰数据，就只需要淘汰队首即可。仍然有个问题，如果有个数据在 1 分钟访问了 1000次，再后 1 分钟没有访问这个数据，但是有其他的数据访问，就导致了我们这个热点数据被淘汰。 LFU：最近最少频率使用，利用额外的空间记录每个数据的使用频率，然后选出频率最低进行淘汰。这样就避免了 LRU 不能处理时间段的问题。 上面
TinyLFU: A Highly Efficient Cache Admission Policy
01-16 1060
缓存是计算机科学中可以提高系统性能的最基本、最有效的一种方法之一。当完整的数据不适合全部缓存时，通过将一小部分数据存放到更快、更接近应用程序的内存中来提高性能。缓存可以提高性能的最直观原因在于数据的访问都表现出相当程度的“局部性”。更正式的表征这种“局部性”的方式，是通过概率分布来描述所有可能的数据项访问频率，在许多计算机科学的领域内，这种概率都表现出高度偏斜，也就是说少数的数据项会比其他数据项更可能被访问。并且在非常多的场景中，访问模式和概率分布会随着时间而变化，这种现象被称为“时间局部性”。 当访问一
论文《TinyLFU: A Highly Ecient Cache Admission Policy》阅读笔记
weixin_34060741的博客
08-21 974
1. Introduction LFU的局限： LFU实现需要维护大而复杂的元数据（频次统计数据等） 大多数实际工作负载中，访问频率随着时间的推移而发生根本变化（这是外卖业务不适合朴素LFU的根本原因） 针对LFU的问题，已经存在了一些LFU的替代或优化方案，例如WLFU（Window LFU）： 老化机制 限制采样为：最后W次访问...
LFU LRU和TinyLFU
define_us的专栏
01-16 823
LFU Least Frequently Used。在数据访问随时间概率不变时，这种缓存的命中率是最高的。而且LFU的成本也是最高的。 LRU 依赖于“时间局部性”的一种替代LFU的缓存方案叫做LRU，LRU中最近被访问的数据项都会被插入缓存，而当缓存满时，最久未被访问的会被淘汰。相比于LFU，LRU的性能会更高，而且自动适应数据的时间局部性，并且可以应对数据的突发流量。但是在实际的场景中，LRU需要更大的缓存空间，才能和LFU达到相同的缓存命中率。 LRU的典型实现如下 对于访问的节点，移送到/建立在
使用Swift模拟Window-LFU
Cwift的专栏
08-23 1836
今天参加了阿里2015的校招的机试，大题开放题比较多，有一道大题是Window-LFU比较有意思，当时题目搞了半天没搞明白让干啥- -题目大概是这样的：实现一个Window-LFU缓存（其实就是用数组去缓存，当时差点用NSCache去做），要在API中暴露set、get、remove方法，并且可以指定cache的长度和window的大小。我用Swift实现的，当时做的时候时间比较紧没有做的太完整，
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值