redis持久化

所有内容来自《redis实战》

1. rdb持久化

1. bgsave 会调用有一个fork来创建一个子进程，然后子进程负责将快照写进磁盘，而父进程则继续处理命令请求。
2. 使用save命令的话，服务器会在快照处理完之前，不会再接收新的命令 ，是一个阻塞操作。
3. save 60 10000 会从最近一次快照算起，60秒内有10000写入 就会自动触发bgsave命令。 如果配置了多个save选项，只要满足条件就会执行bgsave。
4. 如果从服务器发起sync操作的话，主服务器没有bgsave操作，或者并非刚刚执行完bgsave操作，那么主服务器就会执行一次bgsave操作。

如果系统真的发生崩溃，用户将会丢失最近一次快照之后更改的所有数据。因此快照适用于那些即使丢失一部分数据也不会造成问题的应用程序，那系诶不能接受丢数据的， 不应考虑这种类型。

如果打算用快照持久化，最好将服务器运行在于生产服务器相同或者相似的机器上面，使用相同的save配置。

因为bgsave会造成卡顿，可以考虑通过手动来执行bgsave和save命令。可以控制卡顿发生的时间，可以选择在低峰来执行。可以通过脚本来定时执行。

2. aof持久化

有三种选择
always 每个写命令，都要同步到磁盘。
everysec 每秒来执行一次。
no 让操作系统柜来决定应该何时来进行同步

选择每秒来执行的话，可以将损失降到1秒，这种模式和不使用持久化特性相差无几。当硬盘写数据的时候，redis还会优雅地放慢自己的速度以适应硬盘的最大写速度。

由操作系统选择来执行的话，一般不会对性能造成影响，但是系统奔溃的话，将导致使用这种选项的服务器丢失不定量的数据。另外，如果用户的磁盘处理写入操作的速度不够快的话，那么当缓冲区被等待写入磁盘的数据填满时，redis的写入操作会被阻塞，并导致redis处理命令请求的速度变慢。

3. aof的缺陷

因为redis一直在写命令的话，会导致aof的文件越来越大。极端情况下回用完硬盘的空间。因为redis在重启之后需要重新执行aof文件记录的写命令来还原数据集，如果文件特别大， 那么还原操作做执行的时间可能就会非常长。

使用bgrewriteaof 会通过移除aof中的重复命令来重邪恶aof文件，使aof文件尽可能的小。
auto-aof-rewrite-min-size 64m
auto-aof-rewrite-percentage 100
当aof的文件大小大于64m，并且aof文件的体积比上一次重写之后的体积大了至少一倍，redis将执行bgrewriteaof命令。

复制

复制 可以让其他服务器拥有一个不断更新的数据副本，从而使得拥有数据副本的服务器可以用于处理客户端发送的读请求。

redis通过ip地址和端口号来连接主服务器，对于一个正在运行的redis服务器，用户可以通过slaveof no one 来让服务器终止复制操作，不在接受主服务器的数据更新，也可以通过slaveof host port来让服务器开始复制一个新的主服务器。

复制过程：

1. 建立连接， 先发送rdb，然后发送缓冲区数据，然后每次执行新的写命令，也都会同步给从服务器。

判断是否已经将已知所有的数据都保存到硬盘里面了，可以查看info aof_pending_bio_fsync 的值是否为0.

系统故障处理

redis-check-aof 会删除出错的命令以及其后面的命令，保留出错之前的命令。
Usage: redis-check-aof [--fix] <file.aof>
redis-check-dump 查看快照文件的状态。
Usage: redis-check-dump <dump.rdb>

更换故障主服务器

A主服务器，B从服务器
当A挂掉之后
更换计划：首先向机器B发送一个save命令，让他创建一个新的快照文件，接着将这个快照文件发送给C，并在c上面启动redis，最后让机器B成为机器C的从服务器。