redis数据可持久化

1.快照（snapshats）

　　1-1：配置文件

　　　　save 900 1

　　　　save 300 10 

　　　　save 60 10000

　　　　dbfilename dump.rdb  （存储文件）

　　　　含义：指定在多长时间内，有多少次更新操作，就将数据同步到数据文件，可以多个条件配合

　　1-2：可以自己手动存储

　　　　save 命令执行一个同步保存操作，将当前 Redis 实例的所有数据快照(snapshot)以 RDB 文件的形式保存到硬盘。

　　　　一般来说，在生产环境很少执行 SAVE 操作，因为它会阻塞所有客户端，保存数据库的任务通常由 BGSAVE 命令异步地执行。

　　　　然而，如果负责保存数据的后台子进程不幸出现问题时，SAVE 可以作为保存数据的最后手段来使用。

　 原理

• Redis forks.
• 子进程开始将数据写到临时RDB文件中。
• 当子进程完成写RDB文件，用新文件替换老文件。
• 这种方式可以使Redis使用copy-on-write技术。　　

　　特点

　　快照易恢复，文件也小，但是如果遇到宕机等情况的时候快照的数据可能会不完整。此时可能需要启用另一种持久化方式AOF

2.append only mode (aof)

　　配置

　　　　appendonly yes 

　　　　appendfsync everysec （可选参数：

　　　　　　　appendfsync always #always 表示每次有写操作都进行同步，非常慢，非常安全。
　　　　　　　appendfsync everysec #everysec表示对写操作进行累积，每秒同步一次
　　　　　　　官方的建议的everysec，安全，就是速度不够快，如果是机器出现问题可能会丢失1秒的数据。

　　　　　　　也可以手动执行bgrewriteaof进行AOF备份： bgrewriteaof  

　　　　）

　　AOF重写

　　　　AOF文件是可识别的纯文本，它的内容就是一个个的Redis标准命令,
　　　　AOF日志也不是完全按客户端的请求来生成日志的，比如命令 INCRBYFLOAT 在记AOF日志时就被记成一条SET记录，

　　　　因为浮点数操作可能在不同的系统上会不同，所以为了避免同一份日志在不同的系统上生成不同的数据集，所以这里只将操作后的结果通过SET来记录。

　　　　每一条写命令都生成一条日志,AOF文件会很大。

　　　　AOF重写是重新生成一份AOF文件，新的AOF文件中一条记录的操作只会有一次，而不像一份老文件那样，可能记录了对同一个值的多次操作。

　　　　其生成过程和RDB类似，也是fork一个进程，直接遍历数据，写入新的AOF临时文件。

　　　　在写入新文件的过程中，所有的写操作日志还是会写到原来老的 AOF文件中，同时还会记录在内存缓冲区中。

　　　　当重完操作完成后，会将所有缓冲区中的日志一次性写入到临时文件中。然后调用原子性的rename命令用新的 AOF文件取代老的AOF文件

　　　　原理：

　　　　　　AOF重写并不需要对原有AOF文件进行任何的读取，写入，分析等操作，这个功能是通过读取服务器当前的数据库状态来实现的。

　　　　命令：

　　　　　　BGREWRITEAOF， 我们应该经常调用这个命令来来重写

当redis服务器挂掉时，重启时将按照以下优先级恢复数据到内存：

• 如果只配置AOF,重启时加载AOF文件恢复数据；
• 如果同时 配置了RBD和AOF,启动是只加载AOF文件恢复数据;
• 如果只配置RBD,启动是讲加载dump文件恢复数据。

恢复时需要注意，要是主库挂了不能直接重启主库，否则会直接覆盖掉从库的AOF文件，一定要确保要恢复的文件都正确才能启动，否则会冲掉原来的文件。

原文：http://www.cnblogs.com/aifengguo/p/6859090.html