Redis持久化
为什么要做持久化?
Redis是一个内存数据库,那么如果不做持久化的话,当Redis服务器守护进程退出,服务器宕机,计算机断电…就会导致内存中的数据丢失,如果Redis只是作为一个缓存服务器来用的话,那么不会有什么影响,但是如果作为一个内存数据库的话,当上面的情况发生就会出现丢失所有数据的重大事故;
持久化方案
- RDB(默认)
- AOF
RDB(Redis Database)
RDB:当符合一定条件时,redis会自动将内存中的数据进行快照,存储在磁盘上;
-
符合
redis.conf中的配置规则
Redis会单独创建(fork)一个子进程进行持久化,会先将数据写入到一个临时文件中,等到持久化都结束了，在用这个临时文件替换上次持久化好的rdb文件,整个过程中主进程是不进行任何IO操作的这确保了极高的性能，也确保了主进程不会被阻塞;但是这种的缺点是,最后一次持久化的数据可能丢失; -
执行
flushall命令 -
shutdownredis服务端 -
执行
save(同步方式会阻塞) 或者bgsave(异步方式，上图方式) -
执行主从复制操作
我们只需要把dump.rdb文件放到redis服务端启动的目录下就可以实现数据的恢复;
上图展示的操作就是当有rdb文件和没有rdb文件启动redis服务器有没有数据;
- 在主目录下有
rdb文件启动redis服务器发现数据库中有数据 shutdown以后换一个目录启动redis服务器,此目录下没有rdb文件- 启动以后发现没有数据
shutdown以后该目录下出现了rdb文件
由此我们可以得出结论,每一次启动redis时会先进行数据的恢复;也就是对rdb文件的读取;
RDB的优点和缺点
- 优点:
RDB可以最大化Redis的性能：父进程在保存RDB文件时唯一要做的就是fork出一个子进程，然后这个子进程就会处理接下来的所有保存工作，父进程无需执行任何磁盘I/O操作。 - 缺点:使用
RDB方式实现持久化，一旦Redis异常退出，就会丢失最后一次快照以后更改的所有数据。这个时候我们就需要根据具体的应用场景，通过组合设置自动快照条件的方式来将可能发生的数据损失控制在能够接受范围。如果数据相对来说比较重要，希望将损失降到最小，则可以使用AOF方式进行持久化。
AOF(Append Only File)
AOF: redis会将每一个收到的写命令都通过write函数追加到文件中(默认是appendonly.aof)。当redis重启时会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容。当然由于os会在内核中缓存 write做的修改，所以可能不是立即写到磁盘上。这样aof方式的持久化也还是有可能会丢失部分修改。我们可以通过配置文件去配置写入磁盘的时机;
这里默认是不开启aof模式的需要我们自己配置;当aof和rdb都开启时启动时加载aof文件
