同时更改一条数据_Redis系列专题12 -- 数据备份与恢复

本文介绍以下4中数据的备份与恢复方式：

1.通过命令行手动实现数据的备份与恢复

---

备份：

127.0.0.1:6379> saveOK

生成的文件在哪里？不知道的话没关系，执行下面的命令就可以了：

config get dir

如果你没有手动配置过dir的话，一般位于redis的安装目录下。

创建配置文件也可以适应 Bgsave 命令，bg嘛，background，即后台进行备份的命令，通过fork子进程进行快照操作，不会阻塞当前客户端的使用。而save是由主进程执行快照，会阻塞其他请求。

127.0.0.1:6379> BGSAVEBackground saving started

save vs bgsave

恢复：

将备份的dump.rdb文件拷贝到redis的dir(安装目录)下启动redis服务即可。

2.半持久化RDB模式

---

半持久化RDB模式也是Redis备份默认方式，是通过快照(snapshotting)完成的，当符合在Redis.conf配置文件中设置的条件时Redis会自动将内存中的所有数据进行快照并存储在硬盘上，完成数据备份。

Redis进行RDB快照的条件由用户在配置文件中自定义，由两个参数构成：时间和改动的键的个数。当在指定的时间内被更改的键的个数大于指定的数值时就会进行快照。在配置文件中已经预置了3个条件：

save 900 1 #15分钟内有至少1个键被更改则进行快照；save 300 10 #5分钟内有至少10个键被更改则进行快照；save 60 10000 #61分钟内有至少10000个键被更改则进行快照。

默认可以存在多个条件，条件之间是“或”的关系，只要满足其中一个条件，就会进行快照。 如果想要禁用自动快照，只需要将所有的save参数删除即可。Redis默认会将快照文件存储在Redis数据目录，默认文件名为：dump.rdb文件，可以通过配置dir和dbfilename两个参数分别指定快照文件的存储路径和文件名。

Redis实现快照的过程，Redis使用fork函数复制一份当前进程(父进程)的副本(子进程)，父进程继续接收并处理客户端发来的命令，而子进程开始将内存中的数据写入硬盘中的临时文件，当子进程写入完所有数据后会用该临时文件替换旧的RDB文件，至此一次快照操作完成。

执行fork的时操作系统会使用写时复制(copy-on-write)策略，即fork函数发生的一刻父子进程共享同一内存数据，当父进程要更改其中某片数据时，操作系统会将该片数据复制一份以保证子进程的数据不受影响，所以新的RDB文件存储的是执行fork一刻的内存数据。

Redis在进行快照的过程中不会修改RDB文件，只有快照结束后才会将旧的文件替换成新的，也就是说任何时候RDB文件都是完整的。这使得我们可以通过定时备份RDB文件来实 现Redis数据库备份。

RDB文件是经过压缩(可以配置rdbcompression参数以禁用压缩节省CPU占用)的二进制格式，所以占用的空间会小于内存中的数据大小，更加利于传输。

Redis启动后会读取RDB快照文件，将数据从硬盘载入到内存，根据数据量大小与结构和服务器性能不同，通常将一个记录一千万个字符串类型键、大小为1GB的快照文件载入到内存中需花费20～30秒钟。

触发机制-不容忽略方式

缺点：

3.全持久化AOF模式

---

如果数据很重要无法承受任何损失，可以考虑使用AOF方式进行持久化，默认Redis没有开启AOF(append only file)方式的全持久化模式。

在启动时Redis会逐个执行AOF文件中的命令来将硬盘中的数据载入到内存中，载入的速度相较RDB会慢一些，开启AOF持久化后每执行一条会更改Redis中的数据的命令，Redis就会将该命令写入硬盘中的AOF文件。AOF文件的保存位置和RDB文件的位置相同，都是通过dir参数设置的，默认的文件名是appendonly.aof，可以通过appendfilename参数修改该名称。

Redis允许同时开启AOF和RDB，既保证了数据安全又使得进行备份等操作十分容易。此时重新启动Redis后Redis会使用AOF文件来恢复数据，因为AOF方式的持久化可能丢失的数据更少，可以在redis.conf中通过appendonly参数开启Redis AOF全持久化模式：

appendonly yes #开启AOF持久化功能；appendfilename appendonly.aof #AOF持久化保存文件名；appendfsync always #每次执行写入都会执行同步，最安全也最慢；#appendfsync everysec #每秒执行一次同步操作；#appendfsync no #不主动进行同步操作，而是完全交由操作系统来做，每30秒一次，最快也最不安全；auto-aof-rewrite-percentage 100 #当AOF文件大小超过上一次重写时的AOF文件大小的百分之多少时会再次进行重写，如果之前没有重写过，则以启动时的AOF文件大小为依据；auto-aof-rewrite-min-size 64mb #允许重写的最小AOF文件大小配置写入AOF文件后，要求系统刷新硬盘缓存的机制。

AOF三种策略

1.always

2.everysec

3.no

三种策略的选择

AOF重写

AOF 持久化是通过保存被执行的写命令来记录数据库状态的，所以AOF文件的大小随着时间的流逝一定会越来越大；影响包括但不限于：对于Redis服务器，计算机的存储压力；AOF还原出数据库状态的时间增加；

为了解决AOF文件体积膨胀的问题，Redis提供了AOF重写功能：Redis服务器可以创建一个新的AOF文件来替代现有的AOF文件，新旧两个文件所保存的数据库状态是相同的，但是新的AOF文件不会包含任何浪费空间的冗余命令，通常体积会较旧AOF文件小很多。

AOF重写作用：1.减少磁盘占用量 2.加速恢复速度

AOF重新实现方式

1.berewriteaof

2.通过配置实现

AOF重写流程

4.Redis主从复制备份

---

通过持久化功能，Redis保证了即使在服务器重启的情况下也不会损失(或少量损失)数据。但是由于数据是存储在一台服务器上的，如果这台服务器的硬盘出现故障，也会导致数据丢失。

为了避免单点故障，我们希望将数据库复制多个副本以部署在不同的服务器上，即使只有一台服务器出现故障其他服务器依然可以继续提供服务，这就要求当一台服务器上的数据库更新后，可以自动将更新的数据同步到其他服务器上，Redis提供了复制(replication)功能可以自动实现同步的过程。通过配置文件在Redis从数据库中配置文件中加入slaveof master-ip master-port即可，主数据库无需配置。

Redis主从复制优点及应用场景， WEB应用程序可以基于主从同步实现读写分离以提高服务器的负载能力。在常见的场景中，读的频率一般比较大，当单机Redis无法应付大量的读请求时，可以通过复制功能建立多个从数据库，主数据库只进行写操作，而从数据库负责读操作，还可以基于LVS+keepalived+Redis对Redis实现均和高可用。

从数据库持久化持久化通常相对比较耗时，为了提高性能，可以通过复制功能建立一个(或若干个)从数据库，并在从数据库中启用持久化，同时在主数据库禁用持久化。

当从数据库崩溃时重启后主数据库会自动将数据同步过来，所以无需担心数据丢失。而当主数据库崩溃时，需要在从数据库中使用SLAVEOF NO ONE命令将从数据库提升成主数据库继续服务，并在原来的主数据库启动后使用SLAVE OF命令将其设置成新的主数据库的从数据库，即可将数据同步回来。

RDB与AOF的比较