深入解析Redis的LRU与LFU算法实现( 三 ) _Redis

阅读完以上的内容，是否感觉似曾相似？实际上LFU counter计算过程就是对访问次数进行了数值归一化，将数据访问次数映射成热度值(counter) ，数值的范围也从[0,+∞)映射到另一个维度的[0,255] 。
3.3.2 LFU Counter分析
仅从代码层面分析研究Redis LFU算法实现会比较抽象且枯燥，无法直观的呈现counter递增概率的算法效果，以及counter数值与访问次数的关系。
在lfu_log_factor为默认值10的场景下，利用Python/ target=_blank class=infotextkey>Python实现Redis LFU算法流程，绘制出LFU counter递增概率曲线图：

文章插图
可以清晰的观察到，当LFU counter数值超过LFU_INIT_VAL之后，曲线出现了垂直下降，递增概率陡降到0.2%左右，随后在底部形成一个较为缓慢的衰减曲线，直至counter数值达到255则递增概率归于0 ，贴合3.3.1章节分析的理论。
保持Redis系统配置默认值的情况下，对同一个数据持续的访问，并采集此数据的LFU counter数值，绘制出LFU counter数值曲线图：

文章插图
随着访问次数的不断增加， LFU counter数值曲线呈现出爬坡式的递增，形态趋近于根号曲线，由此推测出以下观点：

在访问次数相同的情况下， counter数值不是固定的，大概率在一个范围内波动；
在同一个时间段内，数据之间访问次数相差上千次，才可以通过counter数值区分出哪些数据更热，而“温”数据之间可能很难区分热度。

四、总结通过对Redis LRU与LFU算法实现的介绍，我们可以大体了解两种算法策略的优缺点，在Redis运维过程中，可以依据业务数据的特性去选择相应的算法。
如果业务数据的访问较为均匀， OPS或CPU利用率一般不会出现周期性的陡升或陡降，数据没有体现出相对的“冷热”特性，即建议采用LRU算法，可以满足一般的运维需求。
相反，业务具备很强时效性，在活动推广或大促期间，业务某些数据会突然成为热点数据，监控上呈现出OPS或CPU利用率的大幅波动，为了能抓取热点数据便于后期的分析或优化，建议一定要配置成LFU算法。
在Used_memory接近Maxmemory的情况下， Redis一直都采用随机的方式筛选数据，且筛选的个数极其有限，所以， LFU算法无法展现出较大的优势，也可能会淘汰掉比较热的数据。