Redis持久化

redis持久化方式

redis的持久化，是将内存中的数据写入到磁盘中，有两种方式：

1. RDB快照

（1）redis在一定的时间间隔将内存中的数据集快照写入一种RDB格式的文件以保存到磁盘中，这种格式是经过压缩的二进制文件

（2）保存RDB数据的命令有两种：

① save命令，但是此命令会阻塞redis服务的进程，在RDB文件创建完成前，redis不能处理任何命令请求，这是最大的缺陷

② bgsave命令，在生成RDB文件时，会派生出一个子进程专门负责创建RDB文件，在此期间，主进程和子进程同时存在，不会阻塞redis服务进程。一般使用该命令。可通过lastsave命令获取最后一次成功执行快照的时间

（3）优点：

① 采用子进程创建RDB文件，不会对redis服务器性能造成太大影响

② 快照生成的RDB文件，方便网络中传输和保存，也方便将redis数据恢复到历史某一时刻，可以提高数据的安全性，避免宕机造成数据丢失。

（4）缺点：

① 在RDB文件生成的时间点A，在此之后产生的新数据，还未到达另一次生成RDB文件的时刻，如果redis宕机，时间点A之后的数据会丢失，对数据的一致性造成影响，如果业务可以接受一部分数据丢失，可以采用生成RDB的方式

② 快照持久化方法是通过调用fork()方法创建子进程的，当redis内存的数据量比较大的时候，创建子进程和生成RDB文件会占用大量的系统资源和处理时间，对redis服务处理客户端的请求造成影响

2. AOF（写命令）

（1）redis将所有的写命令保存到了一个AOF文件中，通过这些命令，可以实现数据的持久化和数据恢复

（2）可以在redis.conf文件中，通过将appendonly:yes打开创建AOF文件功能。

同步频率有三种方式：

① always：redis执行每个写命令时，都同步写入硬盘，这样会严重降低redis性能；

② everysec：每秒执行一次，显示的在这一秒内执行的写命令同步到硬盘，默认值，推荐；

③ no：不同步到硬盘（让操作系统来决定何时进行同步）。

（3）AOF重写

如果不重写AOF文件，这种持久化方式对性能影响是最小的。但由于redis不断的将写命令保存到AOF文件中，导致AOF文件越来越大，影响以后恢复数据的效率和服务器重启恢复速度，所以redis提供了重写的功能，比如key初始值是0，调用100次incr后变为100，可以一句set key 100代替其100句命令，AOF重写就是干这事。但是AOF在重写的时候会占用大量的CPU和内存资源，导致服务器负载过高，会出现短暂服务暂停的现象，所以Master最好不要做任何持久化工作，有必要时交给slave来完成。

（4）优点：

① 提供了多种同步命令的方式，默认1秒同步一次写命令，做多会丢失1秒内的数据；

② 如果AOF文件有错误，比如在写AOF文件时redis崩溃了，redis提供了多种恢复AOF文件的方式，例如使用redis-check-aof工具修正AOF文件（一般都是最后一条写命令有问题，可以手动取出最后一条写命令）；

③ AOF文件可读性交强，也可手动操作写命令。

（5）缺点：

① AOF文件比RDB文件较大；

② redis负载较高时，RDB文件比AOF文件具有更好的性能；

③ RDB使用快照的方式持久化整个redis数据，而aof只是追加写命令，因此从理论上来说，RDB比AOF方式更加健壮，另外，官方文档也指出，在某些情况下，AOF的确也存在一些bug，比如使用阻塞命令时，这些bug的场景RDB是不存在的。

实际应用和性能解决方案

（1）有些情况下，我们只想利用Redis的缓存功能，并不像使用 Redis 的持久化功能，那么这时候我们最好停掉 RDB 持久化来最大化Redis性能。

（2）Master最好不要做任何持久化工作，如RDB内存快照和AOF日志文件

（3）如果数据比较重要，某个Slave开启AOF备份数据，策略设置为每秒同步一次

（4）为了主从复制的速度和连接的稳定性，Master和Slave最好在同一个局域网内