redis持久化机制与过期策略
RDB的持久化策略
(快照方式，默认持久化方式)： 按照规则定时将内存中的数据同步到磁盘，它有以下4个触发场景。
1. 自己配置的快照规则 vim /redis/bin/ redis.conf；按照save <seconds> <changes>这个规则自己添加或修改规则。
2. save或者bgsave命令
save：将内存的数据同步到磁盘中，这个操作会阻塞客户端的请求(不建议用，太耗时了)。
bgsave：在后台异步执行快照操作，这个操作不会阻塞客户端的请求。
3. 执行flushall清除内存的所有数据时，只要save <seconds> <changes>规则不为空，就会执行快照。
4. 执行复制的时候(集群中 )
快照的实现原理与优缺点：
redis使用fork函数复制出一份当前进程的副本(子进程)；父进程继续处理客户端指令，子进程开始将内存的数据写入硬盘中的临时文件，写入完成后就会替换之前的旧文件。优点：1. 多进程处理，性能最快。缺点：1. 若子进程数据未写完而redis异常退出，就会丢失最后一次快照以后更改的所有数据; 2. 如果数据集比较大的时候，fork可以能比较耗时，造成服务器在一段时间内停止处理客户端的请求。
AOF的持久化策略
开启AOF持久化：vim /redis/bin/ redis.conf 将appendonly默认值no改为yes; 重启后执行对数据的变更命令， 会在bin目录下生成对应的.aof文件， aof文件中会记录所有的操作命令！
AOF优化：
auto-aof-rewrite-percentage 100 表示当前aof文件大小超过上一次aof文件大小的百分之多少的时候会进行重写。如果之前没有重写过，以启动时aof文件大小为准
auto-aof-rewrite-min-size 64mb 限制允许重写最小aof文件大小，也就是文件大小小于64mb的时候，不需要进行重写。
aof重写原理：
执行redis命令的时候，会把命令写入到.aof文件中，.aof文件变得过大时后台会对它进行重写。在将命令写入到.aof时，即使重写过程发生了停机，现有的.aof文件也不会丢失，所以它是绝对安全的。
同步磁盘数据：
redis在变更数据时，命令会实时记录到.aof文件。但是由于操作系统的缓存机制，数据不是直接写入到硬盘，而是写入硬盘缓存，再通过硬盘缓存机制刷新保存到文件。
appendfsync always 每次执行写入都会进行同步 ， 这个是最安全但是是效率比较低的方式
appendfsync everysec 每一秒执行
appendfsync no 不主动进行同步操作，由操作系统去执行，这个是最快但是最不安全的方式
2.4 aof文件损坏以后如何修复：
例如在执行set name wulei时候，文件只记录了set name ，这种不完整的命令是无法被写入磁盘的。我们可以先将.aof文件备份，然后通过redis-check-aof --fix命令修复，它会将一些不合法的命令清理掉，这样就能被持久化了。
如果要保证数据绝对安全： 可以使用 RDB+AOF 方式来持久化。如果同时使用的话， 那么Redis重启时，会优先使用AOF文件来还原数据。
如果可以接受几分钟的数据丢失：可以使用RDB方式，因为AOF速度没有RDB快。
============================ 手动分割线 ==============================
Redis的过期策略
redis过期是(定期删除+惰性删除+内存淘汰机制)来实现的。reids是用内存来缓存的，内存资源很宝贵。所以我们 set key value 的时候一般都会给它设置过期时间。假设redis里放了10万个数据，redis默认会每隔100ms随机抽取设置了过期时间的key来删除(如果一次性检查所有数据，cpu负载过高redis早就死了)，这种方式就叫定期删除。这种策略就会导致很多过期的key并没有被删除，所以还有惰性删除, 也就是在你获取某个key的时候，redis会检查一下，这个key是否过期了，如果是就直接删除不返回任何东西！
但是这种方式还是有问题的，比如10万条全过期了，而redis只定期删除了部分，而客户端有没有对剩下的key操作，key就不会被删除，还是会造成内存的积压。这时候就会走内存淘汰机制，例如：
allkeys-lru：当内存不足以容纳新写入数据时，移除最近最少使用的key。(最常用)
volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的键中，将更早过期时间的key优先移除。(还凑合吧)
noeviction：当内存不足以容纳新写入数据时，新写入操作会报错。(脑残的策略，没人用)
allkeys-random：当内存不足以容纳新写入数据时，随机移除某个key。(脑残的策略，没人用)
volatile-lru：当内存不足以容纳新写入数据时，在设了过期时间的键中，移除最近最少使用的key。(脑残的策略，没人用)
volatile-random：当内存不足以容纳新写入数据时，在设了过期时间的键中，随机移除某个key。(脑残的策略，没人用)
缓存淘汰算法LFU算法
lfu算法是根据数据的历史访问频率来淘汰数据的，其核心思想是"如果数据过去被访问多次，那么将来被访问的频率也更高".
缺点：
1. 有存储成本,需要维护队列的引用计数，2.最后添加的数据容易被移除
LFU算法原理剖析
1. 新加入的数据插入到队列尾部（因为引用计数为1）
2. 队列中的数据被访问后，其引用计数增加，队列重新排序
3. 当需要淘汰数据时，将已经排序的列表最后的数据块删除
缓存淘汰算法LRU算法
根据数据的历史访问记录来进行淘汰数据，其核心思想是“如果数据最近被访问过，那么将来被访问的几率也更高”
LRU算法原理剖析
1. lru按照一定顺序维护着队列
2. 队列中的数据被访问后，数据会被排列到最前面
3. 当需要淘汰数据时，将已经排序的列表最后的数据块删除
手写LRU算法
import java.util.LinkedHashMap; import java.util.Map; // lru是有序的，所以这里继承 LinkedHashMap public class LRUCache<K,V> extends LinkedHashMap<K,V> { private final int CACHE_SIZE; /** * 传递进来最多能缓存多少数据 * * @param cacheSize 缓存大小 */ public LRUCache(int cacheSize) { /* cacheSize是map的初始大小 0.75f是加载因子，容量使用率达到0.75就会扩容一倍 true 表示让 linkedHashMap 按照访问顺序来进行排序，最近访问的放在头部，最老访问的放在尾部。 */ super(cacheSize, 0.75f, true); CACHE_SIZE = cacheSize; } @Override protected boolean removeEldestEntry(Map.Entry<K, V> eldest) { // 当前map中的数据量大于指定的缓存个数的时候，就自动删除最老的数据。 boolean b = size() > CACHE_SIZE; if(b){ System.out.println("清除缓存key:"+eldest.getKey()); } return b; } public static void main(String args[]){ LRUCache<String, String> lruCache = new LRUCache<String, String>(3); lruCache.put("1", "1"); lruCache.put("2", "2"); lruCache.put("3", "3"); lruCache.put("4", "4"); System.out.println("初始化完成:"+lruCache.keySet()); System.out.println(lruCache.get("3")); System.out.println("访问3之后:"+lruCache.keySet()); System.out.println(lruCache.get("2")); System.out.println("访问2之后:"+lruCache.keySet()); } }
