redis持久化及主从复制详解（转）

作者:silenceper

日期：2013-10-03

原文地址: http://silenceper.com/archives/959.html

redis 与memcached 最大的一个区别就是Redis支持数据的持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用。

一、redis提供的持久化：

1). RDB持久化： 
该机制是指在指定的时间间隔内将内存中的数据集快照写入磁盘。 
2). AOF持久化: 
该机制将以日志的形式记录服务器所处理的每一个写操作，在Redis服务器启动之初会读取该文件来重新构建数据库，以保证启动后数据库中的数据是完整的。 
3). 无持久化： 
我们可以通过配置的方式禁用Redis服务器的持久化功能，这样我们就可以将Redis视为一个功能加强版的memcached了。 
4). 同时应用AOF和RDB。

二、RDB机制的优势和劣势：

RDB存在哪些优势呢？ 
1). 一旦采用该方式，那么你的整个Redis数据库将只包含一个文件，这对于文件备份而言是非常完美的。比如，你可能打算每个小时归档一次最近24小时的数据，同时还要每天归档一次最近30天的数据。通过这样的备份策略，一旦系统出现灾难性故障，我们可以非常容易的进行恢复。 
2). 对于灾难恢复而言，RDB是非常不错的选择。因为我们可以非常轻松的将一个单独的文件压缩后再转移到其它存储介质上。 
3). 性能最大化。对于Redis的服务进程而言，在开始持久化时，它唯一需要做的只是fork出子进程，之后再由子进程完成这些持久化的工作，这样就可以极大的避免服务进程执行IO操作了。 
4). 相比于AOF机制，如果数据集很大，RDB的启动效率会更高。

RDB又存在哪些劣势呢？ 
1). 如果你想保证数据的高可用性，即最大限度的避免数据丢失，那么RDB将不是一个很好的选择。因为系统一旦在定时持久化之前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失。 
2). 由于RDB是通过fork子进程来协助完成数据持久化工作的，因此，如果当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟。

三、AOF机制的优势和劣势：

   AOF的优势有哪些呢？ 
1). 该机制可以带来更高的数据安全性，即数据持久性。Redis中提供了3中同步策略，即每秒同步、每修改同步和不同步。事实上，每秒同步也是异步完成的，其效率也是非常高的，所差的是一旦系统出现宕机现象，那么这一秒钟之内修改的数据将会丢失。而每修改同步，我们可以将其视为同步持久化，即每次发生的数据变化都会被立即记录到磁盘中。可以预见，这种方式在效率上是最低的。至于无同步，无需多言，我想大家都能正确的理解它。 
2). 由于该机制对日志文件的写入操作采用的是append模式，因此在写入过程中即使出现宕机现象，也不会破坏日志文件中已经存在的内容。然而如果我们本次操作只是写入了一半数据就出现了系统崩溃问题，不用担心，在Redis下一次启动之前，我们可以通过redis-check-aof工具来帮助我们解决数据一致性的问题。 
3). 如果日志过大，Redis可以自动启用rewrite机制。

（AOF rewrite的触发机制

如果Redis只是将客户端修改数据库的指令重现存储在AOF文件中，那么AOF文件的大小会不断的增加，因为AOF文件只是简单的重现存储了客户端的指令，而并没有进行合并。对于该问题最简单的处理方式，即当AOF文件满足一定条件时就对AOF进行rewrite，rewrite是根据当前内存数据库中的数据进行遍历写到一个临时的AOF文件，待写完后替换掉原来的AOF文件即可。

Redis触发AOF rewrite机制有三种：

1、Redis Server接收到客户端发送的BGREWRITEAOF指令请求，如果当前AOF/RDB数据持久化没有在执行，那么执行，反之，等当前AOF/RDB数据持久化结束后执行AOF rewrite

2、在Redis配置文件redis.conf中，用户设置了auto-aof-rewrite-percentage和auto-aof-rewrite-min-size参数，并且当前AOF文件大小server.aof_current_size大于auto-aof-rewrite-min-size(server.aof_rewrite_min_size)，同时AOF文件大小的增长率大于auto-aof-rewrite-percentage(server.aof_rewrite_perc)时，会自动触发AOF rewrite

3、用户设置“config set appendonly yes”开启AOF的时，调用startAppendOnly函数会触发rewrite）

4). AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。事实上，我们也可以通过该文件完成数据的重建。

 AOF的劣势有哪些呢？ 
1). 对于相同数量的数据集而言，AOF文件通常要大于RDB文件。 
2). 根据同步策略的不同，AOF在运行效率上往往会慢于RDB。总之，每秒同步策略的效率是比较高的，同步禁用策略的效率和RDB一样高效。

四、持久化的配置

1. Snapshotting: 
缺省情况下，Redis会将数据集的快照dump到dump.rdb文件中。此外，我们也可以通过配置文件来修改Redis服务器dump快照的频率，在打开6379.conf文件之后，我们搜索save，可以看到下面的配置信息： 
save 900 1               #在900秒(15分钟)之后，如果至少有1个key发生变化，则dump内存快照。 
save 300 10             #在300秒(5分钟)之后，如果至少有10个key发生变化，则dump内存快照。 
save 60 10000         #在60秒(1分钟)之后，如果至少有10000个key发生变化，则dump内存快照。

2. Dump快照的机制： 
1). Redis先fork子进程。 
2). 子进程将快照数据写入到临时RDB文件中。 
3). 当子进程完成数据写入操作后，再用临时文件替换老的文件。

3. AOF文件： 
上面已经多次讲过，RDB的快照定时dump机制无法保证很好的数据持久性。如果我们的应用确实非常关注此点，我们可以考虑使用Redis中的AOF机制。对于Redis服务器而言，其缺省的机制是RDB，如果需要使用AOF，则需要修改配置文件中的以下条目： 
将 appendonly no 改为 appendonly yes 
从现在起，Redis在每一次接收到数据修改的命令之后，都会将其追加到AOF文件中。在Redis下一次重新启动时，需要加载AOF文件中的信息来构建最新的数据到内存中。

4. AOF的配置： 
在Redis的配置文件中存在三种同步方式，它们分别是： 
appendfsync always      #每次有数据修改发生时都会写入AOF文件。 
appendfsync everysec   #每秒钟同步一次，该策略为AOF的缺省策略。 
appendfsync no           #从不同步。高效但是数据不会被持久化。

5. 如何修复坏损的AOF文件： 
1). 将现有已经坏损的AOF文件额外拷贝出来一份。 
2). 执行"redis-check-aof --fix <filename>"命令来修复坏损的AOF文件。 
3). 用修复后的AOF文件重新启动Redis服务器。

6. Redis的数据备份： 
在Redis中我们可以通过copy的方式在线备份正在运行的Redis数据文件。这是因为RDB文件一旦被生成之后就不会再被修改。Redis每次都是将最新的数据dump到一个临时文件中，之后在利用rename函数原子性的将临时文件改名为原有的数据文件名。因此我们可以说，在任意时刻copy数据文件都是安全的和一致的。鉴于此，我们就可以通过创建cron job的方式定时备份Redis的数据文件，并将备份文件copy到安全的磁盘介质中。

五、实现主从的复制 master/slave

从服务器的配置：

在配置文件找到 REPLICATION 区域并加入:

slaveof 192.168.1.103 6379  //slaveif 主服务器ip 主服务器端口

//RDB持久化默认开启

//为从服务器开启AOF持久化

[shell]dir ./  //默认appendonly yesappendfilename appendonly.aof[/shell]

主服务器配置采用了默认规则.

这样就可以实现master上的数据 复制到slave上了！

其他操作:

1、用redis-cli bgsave 命令每天凌晨一次持久化一次master redis上的数据，并CP到其它备份服务器上。 
2、用redis-cli bgrewriteaof 命令每半小时持久化一次 slave redis上的数据，并CP到其它备份服务器上。 
3、写个脚本 ，定期get master和slave上的key,看两个是否同步，如果没有同步，及时报警。

测试

在master 上添加数据

[shell]redis 192.168.1.103:6379> set name silenceperOK[/shell]

在slave 上可以使用get name 获取数据了

[shell]redis 192.168.1.104:6379> get name"silenceper"[/shell]

使用phpRedisAdmin 更加直观的看到数据的更改。

六、主从复制的原理

无论是初次连接还是重新连接， 当建立一个从服务器时， 从服务器都将向主服务器发送一个  SYNC  命令。

接到  SYNC  命令的主服务器将开始执行  BGSAVE  ， 并在保存操作执行期间， 将所有新执行的写入命令都保存到一个缓冲区里面。

当  BGSAVE  执行完毕后， 主服务器将执行保存操作所得的  .rdb  文件发送给从服务器， 从服务器接收这个  .rdb  文件， 并将文件中的数据载入到内存中。

之后主服务器会以 Redis 命令协议的格式， 将写命令缓冲区中积累的所有内容都发送给从服务器。

你可以通过 telnet 命令来亲自验证这个同步过程： 首先连上一个正在处理命令请求的 Redis 服务器， 然后向它发送  SYNC  命令， 过一阵子， 你将看到 telnet 会话（session）接收到服务器发来的大段数据（ .rdb  文件）， 之后还会看到， 所有在服务器执行过的写命令， 都会重新发送到 telnet 会话来。

即使有多个从服务器同时向主服务器发送  SYNC  ， 主服务器也只需执行一次 BGSAVE  命令， 就可以处理所有这些从服务器的同步请求。

从服务器可以在主从服务器之间的连接断开时进行自动重连， 在 Redis 2.8 版本之前， 断线之后重连的从服务器总要执行一次完整重同步（full resynchronization）操作， 但是从 Redis 2.8 版本开始， 从服务器可以根据主服务器的情况来选择执行完整重同步还是部分重同步（partial resynchronization）。