Redis持久化（三）

Redis持久化

Redis提供了哪些持久化机制

    1. RDB持久化：

    该机制是指在指定的时间间隔内将内存中的数据集快照写入磁盘。    

    2. AOF持久化:

    该机制将以日志的形式记录服务器所处理的每一个写操作，在Redis服务器启动之初会读取该文件来重新构建数据库，以保证启动后数据库中的数据是完整的。

    3. 无持久化：

    我们可以通过配置的方式禁用Redis服务器的持久化功能，这样我们就可以将Redis视为一个功能加强版的memcached了。

    4. 一般情况下，项目中是同时应用AOF和RDB。

 

RDB机制的优势和劣势

Redis DataBase

RDB存在哪些优势呢？

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

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

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

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

    

RDB又存在哪些劣势呢？

    1. 如果你想保证数据的高可用性，即最大限度的避免数据丢失，那么RDB将不是一个很好的选择。因为系统一旦在定时持久化之前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失。

    2. 由于RDB是通过fork子进程来协助完成数据持久化工作的，因此，如果当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟。

    

AOF机制的优势和劣势

Append only file

AOF的优势有哪些呢？

    1. 该机制可以带来更高的数据安全性，即数据持久性。Redis中提供了3种同步策略，即每秒同步、每修改同步和不同步。事实上，每秒同步也是异步完成的，其效率也是非常高的，所差的是一旦系统出现宕机现象，那么这一秒钟之内修改的数据将会丢失。而每修改同步，我们可以将其视为同步持久化，即每次发生的数据变化都会被立即记录到磁盘中。可以预见，这种方式在效率上是最低的。至于无同步，无需多言，我想大家都能正确的理解它。

    2. 由于该机制对日志文件的写入操作采用的是append模式，因此在写入过程中即使出现宕机现象，也不会破坏日志文件中已经存在的内容。然而如果我们本次操作只是写入了一半数据就出现了系统崩溃问题，不用担心，在Redis下一次启动之前，我们可以通过redis-check-aof工具来帮助我们解决数据一致性的问题。

    3. 如果日志过大，Redis可以自动启用rewrite机制。即Redis以append模式不断的将修改数据写入到老的磁盘文件中，同时Redis还会创建一个新的文件用于记录此期间有哪些修改命令被执行。因此在进行rewrite切换时可以更好的保证数据安全性。

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

AOF的劣势有哪些呢？

1. 对于相同数量的数据集而言，AOF文件通常要大于RDB文件。

    2. 根据同步策略的不同，AOF在运行效率上往往会慢于RDB。总之，每秒同步策略的效率是比较高的，同步禁用策略的效率和RDB一样高效持久化配置

Snapshotting

    缺省情况下，Redis会将数据集的快照dump到dump.rdb文件中。此外，我们也可以通过配置文件来修改Redis服务器dump快照的频率，在打开redis.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内存快照。

Dump快照的机制

1. Redis先fork子进程。

    2. 子进程将快照数据写入到临时RDB文件中。

    3. 当子进程完成数据写入操作后，再用临时文件替换老的文件。

AOF文件

    RDB的快照定时dump机制无法保证很好的数据持久性。如果应用中确实非常关注此点，我们可以考虑使用Redis中的AOF机制。对于Redis服务器而言，其缺省的机制是RDB，如果需要使用AOF，则需要修改配置文件中的以下条目：

  将appendonly no改为appendonly yes。

从现在起，Redis在每一次接收到数据修改的命令之后，都会将其追加到AOF文件中。在Redis下一次重新启动时，需要加载AOF文件中的信息来构建最新的数据到内存中。

AOF的配置

   在Redis的配置文件中存在三种同步方式，它们分别是：

    appendfsync always     #每次有数据修改发生时都会写入AOF文件。

    appendfsync everysec  #每秒钟同步一次，该策略为AOF的缺省策略。

    appendfsync no          #从不同步。高效但是数据不会被持久化。

    

如何修复坏损的AOF文件

 

    1. 将现有已经坏损的AOF文件额外拷贝出来一份。

    2. 执行"redis-check-aof --fix <filename>"命令来修复坏损的AOF文件。

3. 用修复后的AOF文件重新启动Redis服务器。   

 

Redis的数据备份

 

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

 

redis.conf介绍

Redis 支持很多的参数，但都有默认值。

l daemonize:

默认情况下，redis 不是在后台运行的，如果需要在后台运行，把该项的值更改为yes

l pidfile

当Redis 在后台运行的时候，Redis 默认会把pid 文件放在/var/run/redis.pid，你可以配

置到其他地址。当运行多个redis 服务时，需要指定不同的pid 文件和端口

l bind

指定Redis 只接收来自于该IP 地址的请求，如果不进行设置，那么将处理所有请求，在

生产环境中最好设置该项

l port

监听端口，默认为6379

l timeout

设置客户端连接时的超时时间，单位为秒。当客户端在这段时间内没有发出任何指令，

那么关闭该连接

l loglevel

log 等级分为4 级，debug, verbose, notice, 和warning。生产环境下一般开启notice

l logfile

配置log 文件地址，默认使用标准输出，即打印在命令行终端的窗口上

l databases

设置数据库的个数，可以使用SELECT <dbid>命令来切换数据库。默认使用的数据库是0

l save

设置Redis 进行数据库镜像的频率。

if(在60 秒之内有10000 个keys 发生变化时){

进行镜像备份

}else if(在300 秒之内有10 个keys 发生了变化){

进行镜像备份

}else if(在900 秒之内有1 个keys 发生了变化){

进行镜像备份

}

l rdbcompression

在进行镜像备份时，是否进行压缩

l dbfilename

镜像备份文件的文件名

l dir

数据库镜像备份的文件放置的路径。这里的路径跟文件名要分开配置是因为Redis 在进

行备份时，先会将当前数据库的状态写入到一个临时文件中，等备份完成时，再把该该

临时文件替换为上面所指定的文件，而这里的临时文件和上面所配置的备份文件都会放

在这个指定的路径当中

l slaveof

设置该数据库为其他数据库的从数据库

l masterauth

当主数据库连接需要密码验证时，在这里指定

l requirepass

设置客户端连接后进行任何其他指定前需要使用的密码。警告：因为redis 速度相当快，

所以在一台比较好的服务器下，一个外部的用户可以在一秒钟进行150K 次的密码尝试，

这意味着你需要指定非常非常强大的密码来防止暴力破解。

l maxclients

限制同时连接的客户数量。当连接数超过这个值时，redis 将不再接收其他连接请求，

客户端尝试连接时将收到error 信息。

l maxmemory

设置redis 能够使用的最大内存。当内存满了的时候，如果还接收到set 命令，redis 将

先尝试剔除设置过expire 信息的key，而不管该key 的过期时间还没有到达。在删除时，

将按照过期时间进行删除，最早将要被过期的key 将最先被删除。如果带有expire 信息

的key 都删光了，那么将返回错误。这样，redis 将不再接收写请求，只接收get 请求。

maxmemory 的设置比较适合于把redis 当作于类似memcached 的缓存来使用。

l appendonly

默认情况下，redis 会在后台异步的把数据库镜像备份到磁盘，但是该备份是非常耗时

的，而且备份也不能很频繁，如果发生诸如拉闸限电、拔插头等状况，那么将造成比较

大范围的数据丢失。所以redis 提供了另外一种更加高效的数据库备份及灾难恢复方式。

开启append only 模式之后，redis 会把所接收到的每一次写操作请求都追加到

appendonly.aof 文件中，当redis 重新启动时，会从该文件恢复出之前的状态。但是这样会造成appendonly.aof 文件过大，所以redis 还支持了BGREWRITEAOF 指令，对

appendonly.aof 进行重新整理。所以我认为推荐生产环境下的做法为关闭镜像，开启

appendonly.aof，同时可以选择在访问较少的时间每天对appendonly.aof 进行重写一次。

l appendfsync

设置对appendonly.aof 文件进行同步的频率。always 表示每次有写操作都进行同步，

everysec 表示对写操作进行累积，每秒同步一次。这个需要根据实际业务场景进行配置

l vm-enabled

是否开启虚拟内存支持。因为redis 是一个内存数据库，而且当内存满的时候，无法接

收新的写请求，所以在redis 2.0 中，提供了虚拟内存的支持。但是需要注意的是，redis

中，所有的key 都会放在内存中，在内存不够时，只会把value 值放入交换区。这样保

证了虽然使用虚拟内存，但性能基本不受影响，同时，你需要注意的是你要把

vm-max-memory 设置到足够来放下你的所有的key

l vm-swap-file

设置虚拟内存的交换文件路径

l vm-max-memory

这里设置开启虚拟内存之后，redis 将使用的最大物理内存的大小。默认为0，redis 将

把他所有的能放到交换文件的都放到交换文件中，以尽量少的使用物理内存。在生产环

境下，需要根据实际情况设置该值，最好不要使用默认的0

l vm-page-size

设置虚拟内存的页大小，如果你的value 值比较大，比如说你要在value 中放置博客、

新闻之类的所有文章内容，就设大一点，如果要放置的都是很小的内容，那就设小一点。

l vm-pages

设置交换文件的总的page 数量，需要注意的是，page table 信息会放在物理内存中，每8 个page 就会占据RAM 中的1 个byte。总的虚拟内存大小 ＝ vm-page-size * vm-pages

l vm-max-threads

设置VM IO 同时使用的线程数量。因为在进行内存交换时，对数据有编码和解码的过

程，所以尽管IO 设备在硬件上本上不能支持很多的并发读写，但是还是如果你所保存

的vlaue 值比较大，将该值设大一些，还是能够提升性能的

l glueoutputbuf

把小的输出缓存放在一起，以便能够在一个TCP packet 中为客户端发送多个响应，具体原理和真实效果我不是很清楚。所以根据注释，你不是很确定的时候就设置成yes

l hash-max-zipmap-entries

在redis 2.0 中引入了hash 数据结构。当hash 中包含超过指定元素个数并且最大的元素没有超过临界时，hash 将以一种特殊的编码方式（大大减少内存使用）来存储，这里可以设置这两个临界值

l activerehashing

开启之后，redis 将在每100 毫秒时使用1 毫秒的CPU 时间来对redis 的hash 表进行重新hash，可以降低内存的使用。当你的使用场景中，有非常严格的实时性需要，不能够接受Redis 时不时的对请求有2 毫秒的延迟的话，把这项配置为no。如果没有这么严格的实时性要求，可以设置为yes，以便能够尽可能快的释放内存