Redis 论程序的健壮性 ——就看Redis

“众里寻他千百度，蓦然回首，那人却在，灯火阑珊处”。多年的IT生涯，一直希望自己写的程序能够有很强的健壮性，也一直希望能找到一个高可用的标杆程序去借鉴学习，不畏惧内存溢出、磁盘满了、断网、断电、机器重启等等情况。但意想不到的是，这个标杆程序竟然就是从一开始就在使用的分布式缓存——Redis。

Redis（Remote Dictionary Server )，即远程字典服务，是 C 语言开发的一个开源的高性能键值对（key-value）的内存数据库。由于它是基于内存的所以它要比基于磁盘读写的数据库效率更快。因此Redis也就成了大家解决数据库高并发访问、分布式读写和分布式锁等首选解决方案。

那么既然它是基于内存的，如果内存满了怎么办？程序会不会崩溃？既然它是基于内存的，如果服务器宕机了怎么办？数据是不是就丢失了？既然它是分布式的，这台Redis服务器断网了怎么办？

今天我们就一起来看看Redis的设计者，一名来自意大利的小伙，是如何打造出一个超强健壮性和高可用性的程序，从而不惧怕这些情况。

 

一、 Redis的内存管理策略——内存永不溢出

---

Redis主要有两种策略机制来保障存储的key-value数据不会把内存塞满，它们是：过期策略和淘汰策略。

1、 过期策略

用过Redis的人都知道，我们往Redis里添加key-value的数据时，会有个选填参数——过期时间。如果设置了这个参数的值，Redis到过期时间后会自行把过期的数据给清除掉。“过期策略”指的就是Redis内部是如何实现将过期的key对应的缓存数据清除的。

在Redis源码中有三个核心的对象结构：redisObject、redisDb和serverCron。

• redisObject：Redis 内部使用redisObject 对象来抽象表示所有的 key-value。简单地说，redisObject就是string、hash、list、set、zset的父类。为了便于操作，Redis采用redisObject结构来统一这五种不同的数据类型。

• redisDb：Redis是一个键值对数据库服务器，这个数据库就是用redisDb抽象表示的。redisDb结构中有很多dict字典保存了数据库中的所有键值对，这些字典就叫做键空间。如下图所示其中有个“expires”的字典就保存了设置过期时间的键值对。而Redis的过期策略也是围绕它来进行的。

  

• serverCron：Redis 将serverCron作为时间事件来运行，从而确保它每隔一段时间就会自动运行一次。因此redis中所有定时执行的事件任务都在serverCron中执行。

了解完Redis的三大核心结构后，咱们回到“过期策略”的具体实现上，其实Redis主要是靠两种机制来处理过期的数据被清除：定期过期（主动清除）和惰性过期（被动清除）。

• 惰性过期（被动清除）：就是每次访问的时候都去判断一下该key是否过期，如果过期了就删除掉。该策略就可以最大化地节省CPU资源，但是却对内存非常不友好。因为不实时过期了，原本该过期删除的就可能一直堆积在内存里面！极端情况可能出现大量的过期key没有再次被访问，从而不会被清除，占用大量内存。
• 定期过期（主动清除）：每隔一定的时间，会扫描Redis数据库的expires字典中一定数量的key，并清除其中已过期的 key。Redis默认配置会每100毫秒进行1次（redis.conf 中通过 hz 配置）过期扫描，扫描并不是遍历过期字典中的所有键，而是采用了如下方法：

（1）从过期字典中随机取出20个键（server.h文件下ACTIVE_EXPIRE_CYCLE_LOOKUPS_PER_LOOP配置20）

（2）删除这20个键中过期的键

（3）如果过期键的比例超过 25% ，重复步骤 1 和 2

具体逻辑如下图：

因为Redis中同时使用了惰性过期和定期过期两种过期策略，所以在不同情况下使得 CPU 和内存资源达到最优的平衡效果的同时，保证过期的数据会被及时清除掉。

 

2、淘汰策略

---

在Redis可能没有需要过期的数据的情况下，还是会把我们的内存都占满。比如每个key设置的过期时间都很长或不过期，一直添加就有可能把内存给塞满。那么Redis又是怎么解决这个问题的呢？——那就是“淘汰策略”。

官网地址：https://redis.io/topics/lru-c...
Reids官网上面列出的淘汰策略一共有8种，但从实质算法来看只有两种实现算法，分别是LRU和LFU。

LRU（Least Recently Used）：翻译过来是最久未使用，根据时间轴来走，淘汰那些距离上一次使用时间最久远的数据。
LRU的简单原理如下图：

从上图我们可以看出，在容器满了的情况下，距离上次读写时间最久远的E被淘汰掉了。那么数据每次读取或者插入都需要获取一下当前系统时间，以及每次淘汰的时候都需要拿当前系统时间和各个数据的最后操作时间做对比，这么干势必会增加CPU的负荷从而影响Redis的性能。Redis的设计者为了解决这一问题，做了一定的改善，整体的LRU思路如下：

（1）、Redis里设置了一个全局变量 server.lruclock 用来存放系统当前的时间戳。这个全局变量通过serverCron 每100毫秒调用一次updateCachedTime()更新一次值。

（2）、每当redisObject数据被读或写的时候，将当前的 server.lruclock值赋值给 redisObject 的lru属性，记录这个数据最后的lru值。

（3）、触发淘汰策略时，随机从数据库中选择采样值配置个数key, 淘汰其中热度最低的key对应的缓存数据。

注：热度就是拿当前的全局server.lruclock 值与各个数据的lru属性做对比，相差最久远的就是热度最低的。

Redis中所有对象结构都有一个lru字段, 且使用了unsigned的低24位，这个字段就是用来记录对象的热度。

LFU（Least Frequently Used）：翻译成中文就是最不常用。是按着使用频次来算的，淘汰那些使用频次最低的数据。说白了就是“末尾淘汰制”！
刚才讲过的LRU按照最久未使用虽然能达到淘汰数据释放空间的目的，但是它有一个比较大的弊端，如下图：

如图所示A在10秒内被访问了5次，而B在10秒内被访问了3 次。因为 B 最后一次被访问的时间比A要晚，在同等的情况下，A反而先被回收。那么它就是不合理的。LFU就完美解决了LRU的这个弊端，具体原理如下：

上图是末尾淘汰的原理示意图，仅是按次数这个维度做的末尾淘汰，但如果Redis仅按使用次数，也会有一个问题，就是某个数据之前被访问过很多次比如上万次，但后续就一直不用了，它本身按使用频次来讲是应该被淘汰的。因此Redis在实现LFU时，用两部分数据来标记这个数据：使用频率和上次访问时间。整体思路就是：有读写我就增加热度，一段时间内没有读写我就减少相应热度。

不管是LRU还是LFU淘汰策略，Redis都是用lru这个字段实现的具体逻辑，如果配置的淘汰策略是LFU时，lru的低8位代表的是频率，高16位就是记录上次访问时间。整体的LRU思路如下：

（1）每当数据被写或读的时候都会调用LFULogIncr(counter)方法，增加lru低8位的访问频率数值；具体每次增加的数值在redis.conf中配置默认是10（# lfu-log-factor 10）

（2）还有另外一个配置lfu-decay-time 默认是1分钟，来控制每隔多久没人访问则热度会递减相应数值。这样就规避了一个超大访问次数的数据很久都不被淘汰的漏洞。

小结：“过期策略” 保证过期的key对应的数据会被及时清除；“淘汰策略”保证内存满的时候会自动释放相应空间，因此Redis的内存可以自运行保证不会产生溢出异常。