Redis的内存淘汰策略以及持久化
- 1.常见的缓存置换算法
- 2.LRU算法的实现
- 3.Redis的几种内存淘汰策略
- 4.Redis的持久化机制
1.常见的缓存置换算法
缓存与数据库不同，缓存作为其他数据源的副本存在，是为了更快速地存取数据。当数据不存在于缓存中时，就需要从数据源读取数据加载到缓存中。
缓存置换： 缓存的容量是有限的，当数据快把缓存占满的时候，需要及时地把某些数据从缓存中清除掉。最理想的情况就是去置换出未来短期内不会再次访问的数据，但是我们无法预知未来，所以只能从数据在过去的访问情况中寻找规律进行置换。
常见的缓存置换算法有以下几种：
1.Random:随机去淘汰数据。
2.Size:替换掉容量占用最大的内存。
3.FIFO（First Input First Output）: 先进先出的淘汰策略，使用队列实现。
4.LRU (Least Recently Used) ：淘汰最近最少使用的数据（出镜率最高的内存淘汰策略）。
5.LFU （Least frequently used）：最不经常使用。区别于LRU的算法，LRU只记录上次的使用时间，LFU记录一段时间内数据的使用次数，将使用次数最少的数据淘汰掉。
缓存的效率
衡量一个缓存的好坏，有两个重要的指标：缓存命中率和缓存访问效率
缓存命中率 = 访问缓存的次数 ÷ 访问总次数。 越趋近于1，说明缓存命中率越高，性能越好。
缓存访问效率 = 命中缓存的访问时间 ÷ 平均访问时间。 值越小，说明通过缓存去访问一个数据所花费的时间越短，缓存的性能越好。
2.LRU算法的实现
实现策略：
维护一个存放数据的容器，默认容器头部是最近使用的元素，每次访问容器中的元素时，都需要将元素移动到头部，新增元素时也将数据添加到头部。当数据超过容器的容量时，就去移除容器尾部的元素。
1.简单地用链表去实现
维护一个有序单链表，越靠近链表头部的数据越是最近访问的。
查找数据时，去遍历这个链表。如果数据已存在，则将数据返回，并将数据移动到链表头部。
新增缓存时，尝试去将这条数据加入到链表中：
a. 如果此时缓存未满，则将数据加入到链表的头部。
b. 如果此时缓存已满，则将链表尾部的数据直接删除，将此数据加入到链表的头部
举例： 假设缓存的大小为5
a.缓存中目前有4个元素
b.新增一个元素E，此时缓存未满，直接将其加入到链表的头部
c.获取元素D,将元素D返回并将其移动到链表的头部
d.此时再向缓存中增加一个元素F,发现超过缓存的大小了，此时先将尾部的元素删除，再把F添加到链表的头部。
2.用Hash表 + 双向链表去实现
Hash表(key/value字典)用于定位数据位置，使访问的时间复杂度为O(1)
双向链表可用于快速地移动数据位置。
缺点是浪费一个hash表的空间。
实现图：
代码实现：
用Java中现有的HashMap和LinkedList来实现
public class LRUCache {
/** map 用于快速查找 */
private Map<Integer,Integer> map;
/** 链表 存储和淘汰key */
private LinkedList<Integer> linked;
/** 缓存容量 超过这个容量开始淘汰key */
private int capacity;
public LRUCache(int capacity){
linked = new LinkedList();
map = new HashMap<>(capacity);
this.capacity = capacity;
}
public int get(int key){
Integer val = map.get(key);
if (null == val) {
return -1;
}
linked.remove(Integer.valueOf(key));
linked.addFirst(key);
return val;
}
public void put(int key,int value){
// key存在的话更新值，不存在才添加值
Integer val = map.get(key);
if ( null != val){
map.put(key,value);
linked.remove(Integer.valueOf(key));
} else {
if (linked.size() >= capacity){
map.remove(linked.removeLast());
}
map.put(key,value);
}
linked.addFirst(key);
}
}redis中LRU算法的实现方式
redis中使用的是一种近似LRU算法，和真实的LRU算法不太一样。原因是真实的LRU算法需要消耗额外内存，需要对redis现有的数据结构进行较大的改造。
具体的实现方式为：
a. 为每个key额外增加了一个24bit的字段，用于记录这个key最后一次被访问的时间戳。
b. redis执行写操作时，当发现内存超出maxmemory时，随机采样出5个（可配置数量）key，然后去淘汰最旧的key。
c. 如果淘汰后内存还是超出maxmemory，那就继续随机采样淘汰，直到内存低于maxmemory为止。
采样数据来源通过 maxmemory-policy 配置来设置，如果是allkeys 就从所有的key字典中采样，如果是volatile就从带过期时间的key字典中随机采样。
LRU和redis实现的近似LRU的差异:
左一图是理论上LRU算法的应用图，其余的是redis执行的近似LRU的应用图，其中浅灰色代表被淘汰的数据，灰色表示未被淘汰的数据，绿色表示后面加入的数据。
由图中可以看出以下两点：
- 采样的数量越大，近似LRU的效果就越接近严格的LRU算法。
- 同样的采样数量下,redis3.0的近似LRU效果好于redis2.8版本，原因是redis3.0加入了淘汰池，新随机出来的key列表会和淘汰池中的key列表进行融合，淘汰掉最旧的一个key之后，
保留剩余较旧的key列表放入淘汰池中等待下一个循环。淘汰池的大小通过配置文件中的 maxmemory_samples来进行配置。
3.Redis的几种内存淘汰策略
当redis内存超出物理限制时，内存的数据会开始和磁盘产生频繁的交换，这样的交换会让redis的性能急剧下降。为了限制最大使用内存，redis提供了配置参数maxmemory来限制内存超出希望的大小。
当实际内存超出maxmemory时，redis提供了一些策略来淘汰数据:
序号 | 配置策略 | 策略含义 |
1 | volatile-random | 从已设置过期时间的数据集中随机选择数据进行淘汰。 |
2 | volatile-ttl | 从已设置过期时间的数据集中选择将要过期的数据淘汰。 |
3 | volatile-lru | 从已设置过期时间的数据集中选择最近最少使用的数据进行淘汰。 |
4 | volatile-lfu | 从已设置过期时间的数据集中选择最不常用的去淘汰。 |
5 | allkeys-random | 当内存中不足以容纳新写入数据时，在键空间中，随机移除key。 |
6 | allkeys-lru | 当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的key。 |
7 | allkeys-lfu | 当内存不足以容纳新写入数据时，在键空间中，移除最不经常使用的key。 |
8 | no-eviction | 不淘汰数据。 |
其中 1~4面向的数据集是设置了过期时间的key, 5~8面向的数据集是所有key。
4.Redis的持久化机制
redis作为缓存区别于一搬缓存的特性是redis的持久化机制，持久化机制可以保证redis宕机之后，能够根据持久化文件快速地恢复数据，保证redis的数据不会因为故障而丢失。
redis的持久化机制有两种方式：
1）RDB: 快照，一次性的全量备份，内存数据的二进制序列化形式，如果存在老的RDB文件，则新的RDB文件去覆盖掉老的RDB文件。
触发RDB的方式：
a. 通过save命令触发，save命令是一个同步阻塞的命令，如果redis的数据比较多，执行save命令时间过长，对redis的其它操作会被阻塞等待。
b. 通过bgsave命令触发，bgsave是一个异步非阻塞的命令，执行该命令时会fork出一个linux子进程去进行RDB文件的写入，不会影响对redis的其它操作。
c. 自动触发，在redis的配置文件中会有以下配置
3600 1 表示在3600秒内有1个key发生改变时，会生成RDB文件
300 10 表示在300秒内有10个key发生改变时，会生成RDB文件
60 10000 表示在60秒被有10000个key发生改变时，会生成RDB文件
d. 其它触发rdb的操作：
redis客户端通过shutdown命令来关闭服务时，redis服务端收到请求，然后执行同步阻塞的save命令来进行RDB快照文件的生成，执行完毕之后关闭服务器。
主从同步时,当从节点执行全量复制操作时，主节点会执行bgsave命令，并将RDB文件发送给从节点，
bgsave命令的写时复制：
通过bgsave命令进行快照时，redis一边处理收到的数据请求（查找、新增、修改、删除key），一边要进行快照持久化。此时如何保证持久化数据的不出问题？
（比如一个大型的hash字典正在持久化，此时一个请求过来将它删掉了,此时还没持久化完）。
redis使用操作系统的多进程COW（Copy On Write 写时复制）机制来实现快照持久化。
redis在持久化的时候会调用Linux的fork函数fork出一个子进程。子进程和父进程共享内存里面的代码段和数据段。Linux操作系统通过这种机制来解决资源。
此时父进程专注于处理收到的数据请求，子进程去持久化数据，当有请求修改数据时，父进程会先将要修改的数据复制一份，然后再进行修改。这样子进程对应的数据是没有变化的，还是进程产生那一瞬间时的数据。（数据段是由很多操作系统的页面组合而成，父进程修改数据时，会将复制一份数据所在页面然后进行修改，子进程还是备份原页面。）
RDB持久化的缺点：
如果redis宕机了，将丢失最近一次执行快照到宕机时的数据。
2）AOF:可追加文件。连续的增量备份，记录的是内存数据修改的指令记录文本。
AOF原理：
通过配置中的 appendonly 选项来启用aof：
通过 appendfsync 来配置AOF的三种策略：
命令 | 含义 | 优点 | 缺点 |
always | redis每次收到增删改的命令时，都进行一次AOF | 不丢失数据 | IO开销大 |
everysec | 每1秒进行一次AOF写入 | 相比always来说IO开销较小 | 容易丢失1秒内的数据 |
no | 不进行AOF写入，由操作系统去决定什么时候去进行AOF的写入 | 不可靠，不可控 |
不去配置的话 AOF默认的策略是everysec
AOF重写：
随着redis长期的运行，AOF日志会变得十分庞大，所以需要通过AOF重写来给AOF日志进行瘦身。
AOF重写的主要原理就是合并指令和去掉不需要的指令。
AOF重写的主要作用就是减少硬盘占用量和提高恢复重启时的速度。实现AOF重写的方式：
1.用户执行bgrewriteaof命令进行重写
2.通过配置文件配置选项来使redis自动进行AOF重写
配置项 | 含义 |
auto-aof-rewrite-percentage 100 | AOF文件的体积比上一次重写后的体积大了一倍(100%) |
auto-aof-rewrite-min-size 64mb | AOF文件的体积大于64M |
同时满足以上两个选项才进行AOF重写操作。
