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的从服务器。