redis持久化
redis持久化
- RDB snapshotting that takes the data as it exists at one moment in time and writes it to disk.
- AOF, or append-only file (类似mysql binlog)
RDB
Redis 默认是通过RDB方式实现持久化， RBD是经过压缩的二进制文件。
Redis replica使用RDB。
快照持久化，将内存中的数据生成快照保存到磁盘，文件后缀为.rdb
SAVE
同步方式执行，服务器将被阻塞无法处理任何请求。手动调用
BGSAVE
主流方式。
fork子进程 （只有在fork的时候会阻塞），异步执行。父进程可继续处理请求。
手动触发或自动触发， 自动触发配置
save 900 1 // 900秒内至少1次修改 |
任意条件满足，就执行BGSAVE
redis没有专门的命令载入RDB，redis启动过程只要检测到RDB 就会自动载入。
AOF
Append Only File， 默认情况AOF 是关闭的，通过redis.conf配置文件中appendonly yes开启。
AOF是纯文本格式，按顺序记录执行命令， AOF 开启时redis 使用AOF 恢复数据，replay记录的命令来重建。
Append
命令追加，避免频繁的磁盘IO，先写入缓冲区，再sync到文件系统
文件写入（write）和文件同步（fsync）
先写缓冲区，fsync将缓冲区数据写入磁盘。
AOF缓冲刷盘策略：
- appendfsync always： 每执行一次命令保存一次 - 影响TPS，性能差
- appendfsync no：不主动执行磁盘同步，依赖操作系统同步 - 数据安全问题
- appendfsync everysec 每秒一次 ，折中方案，推荐
文件重写
AOF随着时间推移，文件越来越大，导致数据恢复时间将会变长。重写，为了压缩文件打下，将redis当前数据转化为写命令，同步到新的AOF，新的AOF 覆盖旧的AOF。
触发时机： 可以手动，也可以配置执行条件自动触发。
auto-aof-rewrite-min-size （体积，默认64MB）和 auto-aof-rewrite-percentage（前 AOF 大小（aof_current_size）和上一次重写时 AOF 大小（aof_base_size）的比值）
RDB VS AOF
RDB为二进制文件，体积相对更小，恢复速度快；RDB全量数据，如果是定时持久化，服务器宕机，可能会丢失数据
AOF，数据完整性更好（同样也取决于fsync的策略），但记录redis命令文件大小更大，恢复慢
混合模式
一般很少采用RDB 进行数据恢复，因为可能造成大量数据丢失。 而AOF的特性导致恢复（命令重放）很慢，
Redis4提供了基于AOF和RDB的混合持久化机制。
RDB全量 + AOF增量。
持久化策略
不同业务环境，数据安全要求，预算等，不同的持久策略
- 完全没有持久化
- rdb或aof
- rdb+aof 混合
数据库缓存，可以不使用持久化
主从部署（master + 只读replica），master可以关闭持久化确保性能，slave开启AOF 或者slave定时手动AOF rewrite.
引申： 为什么开启主从复制仍然需要持久化? 比如masterslave同一机房，机房停电导致全部重启，没有持久化则数据完全都是。
异地灾备： master定时BGSAVE，RDB文件copy到备份服务器（aws etc...）,或者slave执行bgrewriteaof执行AOF重写，将AOF做为备份。