Redis

redis的淘汰策略

LRU 淘汰策略，当内存使用量达到maxmemory限制时,Redis会从所有键中选择最近最少使用的键(LRU,Least Recently Used)进行淘汰

redis的持久化

Redis是内存数据库，所有数据都存储在内存中。为了避免进程退出导致数据丢失，Redis提供了将内存中的数据持久化到磁盘上的机制。这样在下次重启时，就可以从磁盘恢复数据。

Redis主要有两种持久化方式：RDB和AOF。

RDB

RDB持久化是指在指定的时间间隔内，将内存中的数据集快照（Snapshot） 写入磁盘。它生成一个压缩的二进制文件（默认名为 dump.rdb）

工作原理：

• 创建快照：Redis会fork出一个子进程。
• 子进程负责：将整个内存中的数据序列化并写入一个临时的RDB文件。
• 替换旧文件：当子进程完成写操作后，会用这个新的RDB文件替换旧的RDB文件。

手动触发:

• SAVE命令：同步执行，会阻塞所有客户端请求，直到RDB文件创建完毕。生产环境几乎不用。
• BGSAVE命令：异步执行，后台fork子进程来创建RDB文件，主进程继续提供服务。生产环境常用

自动触发：在配置文件 redis.conf 中设置，例如：(一般为自动触发)

save 900 1      # 在900秒（15分钟）内，至少有1个key发生变化
save 300 10     # 在300秒（5分钟）内，至少有10个key发生变化
save 60 10000   # 在60秒（1分钟）内，至少有10000个key发生变化

满足任意一个条件，就会自动触发BGSAVE。

优点

• 性能高，恢复速度快：RDB是数据的紧凑快照，非常适合用于备份、灾难恢复和快速重启。
• 最大化Redis性能：fork子进程进行持久化，对主进程影响较小。
• 文件紧凑：二进制格式，文件体积小。

缺点

• 数据安全性低：容易丢失最后一次快照之后的数据。根据配置，可能会丢失几分钟的数据。
• fork可能阻塞：如果数据集非常大，fork子进程的过程可能会耗时较长，导致主进程短暂阻塞（毫秒级或秒级，取决于硬件和数据集大小）。

AOF

AOF持久化以日志形式记录每一个写操作命令（例如SET, SADD, LPUSH），并将这些命令追加到AOF文件的末尾。当Redis重启时，会重放（replay） AOF文件中的所有命令来重建数据集。

工作原理

1. 命令追加（Append）：所有写命令在执行后都会被追加到服务器内部的aof_buf缓冲区。
2. 文件写入（Write） & 同步（Sync）：根据配置的appendfsync策略，将缓冲区的内容写入和同步到磁盘的AOF文件。
3. 文件重写（Rewrite）：为了避免AOF文件无限膨胀，Redis会定期根据当前内存中的数据重建一个更小的AOF文件（例如，对于一个key的100次INCR操作，重写后只需记录一条SET key 100的命令）。

appendfsync 策略（核心配置）

• no：由操作系统决定何时同步。性能最好，但数据安全性最差。
• everysec（默认推荐）：每秒同步一次。是性能和数据安全性的良好折衷，最多丢失1秒的数据。
• always：每个写命令都同步。数据最安全，但性能最差，会严重降低Redis速度。

优点

• 数据安全性高：使用everysec策略最多丢失1秒数据；使用always策略则不会丢失任何已确认的写命令。
• 可读性强：AOF文件是纯文本格式，记录了所有操作命令，便于理解和分析。
• 自动重写：通过BGREWRITEAOF命令或自动配置，可以压缩AOF文件。

缺点

• 文件体积大：通常AOF文件会比同数据集的RDB文件大得多。
• 恢复速度慢：重放所有命令来恢复数据，比RDB要慢。
• 性能相对较低：根据同步策略的不同，性能可能会低于RDB。