Redis4.0LFU24位时钟解析

Redis 4.0在LFU淘汰策略中巧妙复用24位lru字段：高16位存储分钟级时间戳（ldt），低8位采用概率递增的对数计数器（logc），以极小空间开销实现高效冷热识别——logc初始为5避免新key被误判为冷数据，通过LFULogIncr()算法让高频访问键缓慢积累计数值（如logc=200对应百万级访问），同时借助lfu-decay-time控制分钟级衰减节奏，使LFU既抗突发流量又具备时效性；配合object freq和idletime命令可直观观测logc与近似空闲时间，但需注意其惰性更新特性及分钟级精度限制，实际部署中合理匹配decay窗口与业务访问频率才是发挥LFU优势的关键。

LFU的24位lru字段怎么拆成16位+8位

Redis 4.0起，redisObject.lru这个24位字段在LFU模式下不再存LRU时间戳，而是复用为两段：高16位存“最后一次访问的分钟级时间戳”（ldt），低8位存对数计数器（logc）。不是按秒、毫秒，就是**精确到分钟**——比如当前Unix时间戳是1744388700，除以60取整得29073145，再对65536（2¹⁶）取模，结果填入高16位。

这个设计本质是空间换精度：省下额外字段开销，但代价是无法区分同一分钟内多次访问；不过对淘汰策略而言，分钟级衰减粒度已足够。

• 高16位（ldt）：只保留time_t / 60 & 0xFFFF，溢出自动截断，不需手动维护
• 低8位（logc）：初始值固定为LFU_INIT_VAL（即5），不是0——避免新key一上来就被误判为“冷数据”
• 两者共存于同一unsigned lru:24位域，编译器自动按位布局，无需用户干预

为什么logc用8位对数计数器而不是线性计数

8位最多表示0–255，如果直接当访问次数用，连一次高频接口调用都撑不住。Redis用概率递增算法LFULogIncr()绕过这个限制：counter越大，下次+1的概率越小。默认lfu-log-factor 10时，counter=200对应的实际访问次数已超百万。

关键点在于“抗突发”：短时间刷100次不会让logc从5飙到105，而是大概率停在20左右。这保证了真正长期高频的key才能积累高logc值。

• 公式实际是1.0 / ((counter - 5) * server.lfu_log_factor + 1)，counter ≤ 5时baseval=0，概率恒为1
• counter == 255时直接返回，不再尝试增长，防止溢出回卷
• 该函数在每次lookupKey命中时调用，未命中的key不触发计数器更新

lfu-decay-time参数如何影响16位时间戳的衰减行为

lfu-decay-time设的是“多少分钟触发一次衰减”，不是时间戳本身的精度。Redis每分钟检查一次，若距上次衰减已超lfu-decay-time分钟，则对所有候选key的logc执行衰减：logc = logc - (now_ldt - ldt) * decay_factor，其中decay_factor固定为1。

也就是说，16位ldt存储的是“最后访问在哪一分钟”，而衰减计算依赖的是两个ldt的差值（单位：分钟）。如果lfu-decay-time设为0，衰减逻辑被跳过，logc永不下降——等同于关闭LFU的时效性。

• ldt本身不随衰减改变，只在每次key被访问时刷新为当前分钟值
• 两次访问间隔若为3分钟，且lfu-decay-time=1，则中间会触发3次衰减（每分钟1次），logc总共减3
• 若lfu-decay-time=10，同样3分钟间隔内不衰减，logc保持不变

用object freq和object idletime验证LFU字段是否生效

object freq命令返回的就是当前key的logc值（低8位），object idletime返回的是基于ldt推算的空闲秒数（注意：它用的是LRU逻辑，但在LFU模式下，ldt仍是分钟级，所以idletime精度会降为分钟×60，可能比真实空闲时间少最多59秒）。

这两个命令不修改lru字段，适合线上观察。但要注意：它们读取的是内存中当前值，而LFU衰减是惰性触发的——只有在淘汰流程或显式调用updateLFU时才真正计算。

• object freq key返回0–255之间的整数，>0说明LFU已参与计数
• object idletime key返回-1表示key不存在，返回正数时需意识到这是近似值
• 想看原始24位值？没有直接命令，只能通过debug object或内存dump解析robj.lru

实际部署时，最易忽略的是lfu-decay-time与业务访问节奏的匹配。比如秒级高频写入的场景，设成10分钟会导致logc长期不衰减，冷热区分失效；而设成0又会让短期热点key迅速沉底。建议先用monitor观察key访问分布，再反推合理的衰减窗口。

今天关于《Redis4.0LFU24位时钟解析》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！