目录
1、Redis
1.1Redis的安装
1.2Redis主从集群搭建
1.3Redis哨兵搭建
1.4Redis持久化
1.4.1持久化算法
持久化算法分为RDB（快照持久化）和AOF（日志持久化）
1.4.1RDB原理
RDB 是 Redis 默认的持久化方式，通过生成某一时刻的全量数据快照（二进制文件）实现持久化。
当触发 RDB 时，Redis 会通过 fork() 系统调用创建一个子进程，子进程负责将内存中的全量数据写入临时 RDB 文件，写入完成后替换旧 RDB 文件。
过程中使用 写时复制（Copy-On-Write, COW）机制：主进程（父进程）继续处理客户端请求，若修改已存在的数据，会复制一份副本供子进程写入，确保子进程读取的是 fork 时刻的快照数据，不影响主进程正常运行。
1.4.2RDB触发方式
手动触发：
save：主进程直接执行 RDB 生成，期间阻塞所有客户端请求（不推荐）。
bgsave：后台异步执行，主进程通过 fork 子进程处理，不阻塞客户端（推荐）。
自动触发：
配置文件中通过 save <seconds> <changes> 定义触发条件（如 save 3600 1 表示 3600 秒内有 1 次修改则触发）。
1.4.3RDB优缺点
优点：
快照文件（.rdb）体积小，恢复速度快（直接加载二进制文件到内存）。
适合全量备份（如每日备份）和灾难恢复。
缺点：
数据安全性低：若在两次快照间隔内 Redis 崩溃，期间的数据会丢失（丢失量取决于快照间隔）。
全量写入成本高：fork 子进程时若数据量大，可能阻塞主进程（fork 耗时与内存量正相关）。
1.4.4AOF原理
客户端的每一条写命令（如修改、删除）都会被追加到 AOF 缓冲区，再根据配置的同步策略写入磁盘 AOF 文件。
为避免 AOF 文件过大（如重复执行 incr key 会导致大量冗余命令），Redis 引入 AOF 重写（Rewrite）机制：通过子进程重新扫描内存数据，生成最小化的命令集（如将 100 次 incr key 合并为 set key 100），替换旧 AOF 文件。
1.4.5AOF配置
同步策略（通过 appendfsync 控制，影响安全性与性能）：
always：每写一条命令就同步到磁盘（安全性最高，性能最差）。
everysec：每秒同步一次（默认，平衡安全性与性能，最多丢失 1 秒数据）。
no：由操作系统决定何时同步（性能最好，安全性最低）。
重写触发：
手动：bgrewriteaof（后台异步执行）。
自动：通过 auto-aof-rewrite-min-size（最小文件大小）和 auto-aof-rewrite-percentage（文件增长比例）配置触发条件。
1.4.6AOF优缺点
优点：
数据安全性高：可通过同步策略控制数据丢失量（最多丢失 1 秒数据）。
命令日志可读性强（文本文件）。
缺点：
AOF 文件体积通常远大于 RDB（尤其未重写时），恢复速度慢（需重新执行所有命令）。
重写过程仍可能占用资源。
1.5淘汰策略
当 Redis 内存使用达到 maxmemory 配置阈值时，会触发淘汰策略释放内存，确保新数据可写入。核心策略分为不淘汰和主动淘汰两类。
不淘汰：
noeviction（默认）：当内存不足时，拒绝所有写操作（返回错误），读操作正常执行。适用于不允许数据丢失的场景（如核心业务数据）。
主动淘汰：
根据淘汰范围（全量键 / 仅过期键）和淘汰规则（随机、LRU、LFU、TTL）分类：
allkeys-random 从所有键中随机淘汰一个键
allkeys-lru 淘汰最近最少使用（LRU）的键
allkeys-lfu 淘汰最不经常使用（LFU）的键
volatile-random 从设置了过期时间的键中随机淘汰
volatile-lru 从设置了过期时间的键中淘汰最近最少使用的键
volatile-lfu 从设置了过期时间的键中淘汰最不经常使用的键
volatile-ttl 从设置了过期时间的键中，淘汰剩余生存时间（TTL）最短的键