Redis持久化操作以及主从同步的配置

大部分人都知道 Redis 是一款用在缓存服务器上的软件，它与 Memcache 类似，都可以存储海量的数据，用在访问量大的 web 网站、聊天记录存放等方面，但是又与 Memcache 不同。

今天介绍下Redis持久化操作以及主从服务器配置。

一：Redis 与 Memcached 的区别

　　1. 支持持久化

　　　　1) Redis 与 Memcached 最大的一个区别就是Redis 支持数据的持久化，可以将内存中的数据保持在磁盘中，且没有缓存时间限制，重启服务的时候可以再次加载进行使用。

　　2. 支持数据类型

　　　　1) Redis 支持更多的数据类型，string 、list 、set 、zset 、hash。

　　3. 数据仓库

　　　　1) 提供多个数据仓库（0-15），默认有16个仓库，可自定义

　　4. 计算能力

　　　　1) 支持在服务器端计算集合的并，交和补集等，还支持多种排序功能，所以 Redis 也可以被看成是一个数据结构服务器。

二：Redis 提供的持久化

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

三：RDB机制的优势与劣势

　　1. RDB 的优势

　　　　1) 采用该方式，那么你的整个 Redis 数据库将只包含一个文件，这对于文件备份而言是非常完美的。比如，你可能打算每个小时归档一次最近24小时的数据，同时还要每天归档一次最近30天的数据。通过这样的备份策略，一旦系统出现灾难性故障，我们可以非常容易的进行恢复。

　　　　2) 对于灾难恢复而言，RDB是非常不错的选择。因为我们可以非常轻松的将一个单独的文件压缩后再转移到其它存储介质上。

　　　　3) 性能最大化。对于 Redis 的服务进程而言，在开始持久化时，它唯一需要做的只是fork出子进程，之后再由子进程完成这些持久化的工作，这样就可以极大的避免服务进程执行IO操作了。

　　　　4) 相比于AOF机制，如果数据集很大，RDB的启动效率会更高。

　　2. RDB 的劣势

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

四：AOF 机制的优势与劣势

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

　　2. 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

　　1. 从服务器的配置

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

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

　　　　// RDB持久化默认开启

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

　　　　[shell]
　　　　dir ./  //默认
　　　　appendonly yes
　　　　appendfilename appendonly.aof
　　　　[/shell]

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

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

　　　　其他操作:

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

　　3. 测试

　　　　在master 上添加数据

　　　　[shell]
　　　　redis 192.168.1.103:6379> set name silenceper
　　　　OK
　　　　[/shell]

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

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

　　　　使用 RedisClient 可以更加直观的看到数据的更改。链接：http://pan.baidu.com/s/1bpGqqQV 密码：lk2f

七：主从复制的原理

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

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

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

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

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

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

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