Redis持久化

RDB：将当前进程数据生成快照保存到硬盘的过程。

两种方式：

1. save：阻塞当前Redis服务器知道RDB过程完成。
2. bgsave：Redis进程fork子进程，完成后自动结束，Redis阻塞只发生在fork阶段。 执行shutdown命令时在没有开启AOF时会自动执行bgsave。

Redis会对采用LZF算法对RDB文件进行压缩处理

• RDB优点

1. RDB是一个紧凑的二进制文件，代表某个时间点上的数据快照，适用于备份、全量复制等场景
2. RDB的数据恢复速度远快于AOF模式

• RDB缺点

1. RDB无法做到实时持久化，且每次都需要fork子进程，执行成本高
2. RDB文件存在多个格式，新老版本无法兼容

AOF：通过日志记录每次写命令，重启时再重新执行AOF文件中的命令打到数据恢复的目的，解决了数据持久化的实时性问题。

文件同步：

1. always：每次写入aof_buf后都需要调用fsync进行同步到AOF的操作。
2. everysec：每次写入aof_buf后调用write操作，fsync操作由专门线程每秒执行一次。
3. no：每次写入aof_buf后调用write操作，同步周期不可控，通常最长30秒

AOF重写机制：减少了文件的占用空间，且更小的AOF文件能更快被Redis加载。

1. 超时数据不再写入文件
2. 删除旧AOF文件中的无效命令
3. 多条写操作合并为一条 AOF过程可以通过调用bgrewriteof手动触发，也可以通过auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数定时触发。

持久化时可能产生的问题：

1. Fork操作过于耗时
   • 使用物理机或者支持高效fork的虚拟机，避免使用Xen
   • Redis实例内存控制在10GB以内
   • 合理配置Linux内存分配策略
   • 降低fork操作的频率
2. 内存消耗过大
   • 部署多个实例的情况下，尽量保证同一时刻只有一个子进程在工作
   • 避免在大量写入操作时做子进程重写操作
3. 硬盘负载过大
   • 不要和其他高硬盘负载的服务部署在一起，如存储服务或消息队列等
   • AOF重写时会消耗大量硬盘IO，可以开启no-appendfsync-on-rewrite默认关闭，在AOF期间不进行fsync操作。
   • 开启AOF功能的Redis用于高流量写入场景时，Redis瓶颈往往存在于AOF同步硬盘上。
   • 配置多个Redis的情况下，可以配置不同实例分盘存储AOF文件。

来源：oschina

链接：https://my.oschina.net/u/4525941/blog/4428361