redis总结

1.redis缓存异常

2.redis的持久化

（AOF和RDB）
AOF append only file
缺点（如果操作日志非常多，redis就会恢复的很缓慢，影响到正常使用）
写后日志：记录redis每一条执行成功的命令
好处：不会阻塞当前写操作
风险：
1.宕机丢失数据
2.AOF是在主线程操作，磁盘写入压力大时，会阻塞下一个操作

AOF三种写回策略（写回时机）避免风险
1.Always 同步写回：写命令执行完，立马同步地将日志写回磁盘；基本不会丢数据，但影响主线程性能
2.everysec 每秒写回，先把日志写到AOF文件的内存缓冲区，隔一秒把缓冲区中的内容写入磁盘，还是有宕机风险；
3.No，操作系统控制的写回，只是先把日志写到AOF文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘；折中方案

日志文件太大
AOF重写，读取数据库最新数据记录（主线程内存），同一个KEY只有一条数据

一个拷贝，两处日志
1。重写过程是由后台子进程bgrewriteaof来完成的，为了避免阻塞主线程，重写日志时，有新的数据写入
1.第一处日志就是指正在使用的AOF日志，Redis会把这个操作写到它的缓冲区。即使宕机了，这个AOF 志的操作仍然是齐全的，可以用于恢复。
2.就是指新的 AOF 重写日志。这个操作也会被写到重写日志的缓冲区。这样，重写日志也不会丢失最新的操作

总而言之：拷贝过程中，重写过程中的新写入操作都会往新旧两处日志记录，旧的为了保证宕机后恢复，新的为了保证新日志的完整

RDB 就是 Redis DataBase 的缩写。
redis数据在内存中的状态信息保存下来，可以认为是一种压缩文件，和 AOF 相比，RDB 记录的是某一时刻的数据状态，并不是操作，所以，在做数据恢复时，我们可以直接把 RDB 文件读入内存，很快地完成恢复

Redis 会使用 bgsave 对当前内存中的所有数据做快照，这个操作是子进程在后台完成的，这就允许主线程同时可以修改数据。
虽然跟 AOF 相比，快照的恢复速度快，但是，快照的频率不好把握，如果频率太低，两次快照间一旦宕机，就可能有比较多的数据丢失。如果频率太高，又会产生额外开销，

Redis 4.0混合使用 AOF 日志和内存快照的方法。简单来说，内存快照以一定的频率执行，在两次快照之间，使用 AOF 日志记录这期间的所有命令操作

关于 AOF 和 RDB 的选择问题，
三点建议：
数据不能丢失时，内存快照和 AOF 的混合使用是一个很好的选择；
如果允许分钟级别的数据丢失，可以只使用 RDB；
如果只用 AOF，优先使用 everysec 的配置选项，因为它在可靠性和性能之间取了一个平衡。

3.redis的缓存淘汰机制
计算机系统中，默认有两种缓存：
CPU 里面的末级缓存，即 LLC，用来缓存内存中的数据，避免每次从内存中存取数据；
内存中的高速页缓存，即 page cache，用来缓存磁盘中的数据，避免每次从磁盘中存取数据。

我会建议把缓存容量设置为总数据量的 15% 到 30%，兼顾访问性能和内存空间开销。

noeviction 策略是不会进行数据淘汰的
volatile-ttl 在筛选时，会针对设置了过期时间的键值对，根据过期时间的先后进行删除，越早过期的越先被删除。
volatile-random 就像它的名称一样，在设置了过期时间的键值对中，进行随机删除。
volatile-lru 会使用 LRU 算法筛选设置了过期时间的键值对。
volatile-lfu 会使用 LFU 算法选择设置了过期时间的键值对。
allkeys-random 策略，从所有键值对中随机选择并删除数据；
allkeys-lru 策略，使用 LRU 算法在所有数据中进行筛选。
allkeys-lfu 策略，使用 LFU 算法在所有数据中进行筛选。

Least Recently Used:关注数据时效性
Least Frequently Used:关注数据频率