Redis 4.0起，24位lru字段在LFU模式下拆为高16位ldt（分钟级时间戳）和低8位logc（对数计数器），ldt= (time_t/60) & 0xFFFF，logc初始为5并用概率递增算法更新。
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访问分布，再反推合理的衰减窗口。
