redis

redis作为缓存，如何实现持久化（RDB）？

❒ RDB全称Redis Database Backup file(Redis数据备份文件)，也被叫做Redis数据快照。简单来说就是把内存中的所有数据都记录到磁盘中。当Redis实例故障重启后，从磁盘读取快照文件，恢复数据。

✅手动触发
[root@localhost ~l# redis-cli
127.0.0.1:6379> save # 由Redis主进程来执行RDB，会阻塞所有命令
ok
127.0.0.1:6379> bgsave # 开启子进程执行RDB，避免主进程受到影响
Background saving started

✅自动触发（通过配置文件）
redis内部有触发RDB的机制，可以在redis.conf文件中找到，格式如下:
# 如果900秒内至少有1个key被修改，则执行bgsave
save 900 1
save 300 10
save 60 10000

✅RDB的执行原理
主进程执行bgsave，调用fork()得到子进程（此时主进程会短暂阻塞，阻塞时间与数据量相关）。
子进程负责将内存中的数据写入临时文件（避免覆盖旧的 RDB 文件）。
子进程写入完成后，用临时文件替换原有的 dump.rdb 文件（copy-on-write，原子操作，确保文件完整性）。
当主进程执行读操作时，访问共享内存。
当主进程执行写操作时，则会拷贝一份数据，执行写操作。

总结：写时复制机制让 fork() 后的主进程和子进程既能共享初始内存（节省资源），又能独立修改数据（互不干扰），是 redis 实现高效后台持久化的重要基础。

✅RDB和AOF各有自己的优缺点，如果对数据安全性要求较高，在实际开发中往往会结合两者来使用。            
                                
持久化方式：定时对整个内存做快照
数据完整性：不完整，两次备份之间会丢失
文件大小：会有压缩，文件体积小
宕机恢复速度：很快
数据恢复优先级：低，因为数据完整性不如AOF
系统资源占用：高，大量CPU和内存消耗
使用场景：可以容忍数分钟的数据丢失，追求更快的启动速度

redis 启动时，若同时开启 RDB 和 AOF，优先加载 AOF 文件（因 AOF 数据更完整）