redis单线程、持久化、过期策略及其内存淘汰策略

原理：

redis使用的是单线程为什么还能这么快？

​ 因为redis 数据都在内存中，是内存级别的运算处理，而且单线程避免了多线程切换的性能损耗问题。

redis处理数据的时间是纳秒级别

redis单线程如何处理那么多的并发客户端？

​ redis采用epoll来实现IO多路复用（linux本身的内核技术），将连接信息和事件放到队列中，依次放到文件事件分派器，事件分派器将事件发送给事件处理器

传统数据库中的ACID：

​ 原子性

​ 一致性

​ 独立性

​ 持久性

持久化

redis持久化之RDB

​ 能够在指定的时间间隔内对数据进行快照存储

​ 可以人为设置rdb触发条件：在N秒内key至少有M次变化

​ redis单独创建（fork）一个子进程来进行持久化，会将数据写入到一个临时文件中（dump.rdb），待持久化过程都结束了，再用这个临时文件替换上次持久化号的文件。

整个过程中主进程不进行IO操作（为了确保高性能）

优点：适用于需要大规模恢复并且对数据恢复完整性不敏感的情况

缺点：宕机后持久化后的数据可能丢失

默认触发生成dump.rdp的情况：

​ 1.900秒内（15分钟）key发生一次改变

​ 2.300秒内（五分钟）key发生10次改变

​ 3.60秒内（一分钟）key发生10000次改变

redis持久化之AOF

​ 以日志形式追加记录redis的每个写操作到appendonly.aof文件中

​ 启动时会读取该文件重新构建数据

​ 防止文件越写越大，增加重写机制，当AOF文件大小超过阈值，redis启动AOF文件压缩，只保留可以恢复数据的最小指令集，可以使用命令bgrewriteaof

指定redis多久生成一次aof文件

​ 1.每秒同步，异步操作，每秒记录，如果一秒内宕机，有数据丢失

​ 2.每修改同步（默认使用），每次发生数据发生变更都会被记录到磁盘中，性能差但是数据完整性比较好

​ 3.不同步，从不同步，更快但是不安全

缺点：

​ 1.相同数据下，AOF文件远大于RDB文件，

​ 2.恢复速度也比RDB慢

只做缓存：

​ 如果只希望数据在服务器运行的时候存在，也可以不使用任何持久化方式

混合持久化方式

AOF在重写时将重写这一刻之前的内存RDB快照文件和增量的AOF修改内存数据的命令日志文件放在一起，都写入新的AOF文件中，新的文件一开始不叫appendonly.aof文件，等到重写完毕，在进行改名，原子的覆盖原有的AOF文件，完成新旧两个AOF文件的替换

AOF根据配置规则在后台自动重写，也可以人为执行命令bgrewriteaof重写AOF。 于是在 Redis 重启的时候，可以先加载 rdb 的内容，然后再重放增量 AOF 日志就可以完全替代之前的 AOF 全量文件重放，重启效率因此大幅得到提升。

过期策略

当redis中缓存的key过期后的操作

1. 定时过期：给key设置定时器，到时间清除
2. 惰性过期：只有在使用到key的时候，判断其有无过期，过期则清除
3. 定期过期（定时过期+惰性过期）：每隔一段时间，扫描数据库中一定数量的key，清除其中已经过期的key

内存淘汰策略

当redis用于缓存的内存不足时的操作

1. noeviction（默认），只读不可写，导致线上业务不能运行
2. volatile-lru，优先淘汰设置了过期时间后使用最少的key，不淘汰没设置过期时间的
3. volatile-ttl，优先淘汰设置了过期后剩余寿命最少的key，不淘汰没设置过期时间的
4. volatile-random，淘汰设置了过期后中随机的key，不淘汰没设置过期时间的
5. allkeys-lru，淘汰所有key中使用最少的key
6. allkeys-random，随机淘汰所有key中的key

如果想同时使用Redis中的持久化功能，就使用volatile-***，可以保留没有设置过期时间的key