数据安全与性能保障
持久化选项
Redis提供了两种不同的持久化方法来将数据存储到硬盘里面。分别是快照(snapshotting)和只追加文件(append-only file, AOF)。快照可以将存在于某一时刻的所有数据都写入硬盘里面，只追加文件会在执行写入命令时，将被执行的写命令复制到硬盘。这两种持久化方法既可以单独使用，也可以同时使用。
- 快照持久化
Redis可以通过创建快照来获得存储在内存里面的数据在某个时间点上的副本。在创建快照之后，用户可以对快照进行备份，可以将快照复制到其他服务器从而创建具有相同数据的服务器副本，还可以将快照留在原地以便重启服务器时使用。
创建快照的方法有以下几种：- 客户端可以通过向Redis发送BGSAVE命令来创建一个快照。对于支持BGSAVE命令的平台来说，Redis会调用fork来创建一个子进程，然后子进程负责将快照写入硬盘，而父进程则继续处理命令请求。
- 客户端还可以通过向Redis发送SAVE命令来创建一个快照，接到SAVE命令的Redis服务器在快照创建完成之前将不再响应任何其他命令。
- 如果⽤户设置了save配置选项，⽐如save 60 10000，那么从Redis最近⼀次创建快照之后开始算起，当“60秒之内有10 000次写⼊”这个条件被满⾜时，Redis就会⾃动触发BGSAVE命令。如果⽤户设置了多个save配置选项，那么当任意⼀个save配置选项所设置的条件被满⾜时，Redis就会触发⼀次BGSAVE命令。
- 当Redis通过SHUTDOWN命令接收到关闭服务器的请求时，或者接收到标准TERM信号时，会执⾏⼀个SAVE命令，阻塞所有客户端，不再执⾏客户端发送的任何命令，并在SAVE命令执⾏完毕之后关闭服务器。
- 当⼀个Redis服务器连接另⼀个Redis服务器，并向对⽅发送SYNC命令来开始⼀次复制操作的时候，如果主服务器⽬前没有在执⾏BGSAVE操作，或者主服务器并⾮刚刚执⾏完BGSAVE操作，那么主服务器就会执⾏BGSAVE命令。
- AOF持久化
AOF持久化会将被执行的写命令写到AOF文件的末尾，以此来记录数据发生的变化。Redis只要从头到尾重新执⾏
⼀次AOF⽂件包含的所有写命令，就可以恢复AOF⽂件所记录的数据集。
appendfsync选项及同步频率
- 重写/压缩AOF⽂件
Redis会不断地将被执⾏的写命令记录到AOF⽂件⾥⾯，所以随着Redis不断运⾏，AOF⽂件的体积也会不断增长，在极端情况下，体积不断增⼤的AOF⽂件甚⾄可能会⽤完硬盘的所有可⽤空间。还有就是因为Redis在重启之后需要通过重新执⾏AOF⽂件记录的所有写命令来还原数据集，所以如果AOF⽂件的体积⾮常⼤，那么还原操作执⾏的时间就可能会⾮常长。
为了解决AOF⽂件体积不断增⼤的问题，⽤户可以向Redis发送BGREWRITEAOF命令，这个命令会通过移除AOF⽂件中的冗余命令来
重写（rewrite）AOF⽂件，使AOF⽂件的体积变得尽可能地⼩。
复制
复制可以让其他服务器拥有⼀个不断地更新的数据副本，从⽽使得拥有数据副本的服务器可以⽤于处理客户端发送的读请求。关系数据库通常会使⽤⼀个主服务器（master）向多个从服务器（slave）发送更新，并使⽤从服务器来处理所有读请求。Redis也采⽤了同样的⽅法来实现⾃⼰的复制特性，并将其⽤作扩展性能的⼀种⼿段。
- 对Redis的复制相关选项进⾏配置
⽤户在启动Redis服务器的时候，指定了⼀个包含slaveof host port选项的配置⽂件，那么Redis服务器将根据该选项给定的IP地址和端⼜号来连接主服务器。对于⼀个正在运⾏的Redis服务器，⽤户可以通过发送SLAVEOF noone命令来让服务器终⽌复制操作，不再接受主服务器的数据更新；也可以通过发送SLAVEOF host port命令来让服务器开始复制⼀个新的主服务器。 - Redis复制的启动过程
从服务器连接主服务器时的步骤：
 - 主从链
创建多个从服务器可能会造成⽹络不可⽤——当复制需要通过互联⽹进⾏或者需要在不同数据中⼼之间进⾏时，尤为如此。因为Redis的主服务器和从服务器并没有特别不同的地⽅，所以从服务器也可以拥有⾃⼰的从服务器，并由此形成主从链（master/slave chaining）。
为了将数据保存到多台机器上⾯，⽤户⾸先需要为主服务器设置多个从服务器，然后对每个从服务器设置appendonly yes选项和appendfsync everysec选项（如果有需要的话，也可以对主服务器进⾏相同的设置），这样的话，⽤户就可以让多台服务器以每秒⼀次的频率将数据同步到硬盘上了。但这还只是第⼀步：因为⽤户还必须等待主服务器发送的写命令到达从服务器，并且在执⾏后续操作之前，检查数据是否已经被同步到了硬盘⾥⾯。 - 检验硬盘写⼊
为了验证主服务器是否已经将写数据发送⾄从服务器，⽤户需要在向主服务器写⼊真正的数据之后，再向主服务器写⼊⼀个唯⼀的虚构值（unique dummy value），然后通过检查虚构值是否存在于从服务器来判断写数据是否已经到达从服务器
判断数据是否已经被保存到硬盘⾥⾯则要困难得多。对于每秒同步⼀次AOF⽂件的Redis服务器来说，⽤户总是可以通过等待1秒来确保数据已经被保存到硬盘⾥⾯；但更节约时间的做法是，检查INFO命令的输出结果中aof_pending_bio_fsync属性的值是否为0，如果是的话，那么就表⽰服务器已经将已知的所有数据都保存到硬盘⾥⾯了。
处理系统故障
⽤户必须做好相应的准备来应对Redis的系统故障。
验证快照⽂件和AOF⽂件
Redis提供了两个命令⾏程序redis-check-aof和redis-check-dump，它们可以在系统故障发⽣之后，检查AOF⽂件和快照⽂件的状态，并在有需要的情况下对⽂件进⾏修复。
更换故障主服务器
假设A、B两台机器都运⾏着Redis，其中机器A的Redis为主服务器，⽽机器B的Redis为从服务器。同时安装了Redis
的机器C⽤作新的主服务器。⾸先向机器B发送⼀个SAVE命令，让它创建⼀个新的快照⽂件，接着将这个快照⽂件发送给机器C，并在机器C上⾯启动Redis。最后，让机器B成为机器C的从服务器。
另⼀种创建新的主服务器的⽅法，就是将从服务器升级（turn）为主服务器，并为升级后的主服务器创建从服务器。
Redis事务
延迟执⾏事务有助于提升性能
⾮事务型流⽔线
⽤户在执⾏pipeline()时传⼊True作为参数，或者不传⼊任何参数，那么客户端将使⽤MULTI和EXEC包裹起⽤户要执⾏的所有命令。另⼀⽅⾯，如果⽤户在执⾏pipeline()时传⼊False为参数，那么客户端同样会像执⾏事务那样收集起⽤户要执⾏的所有命令，只是不再使⽤MULTI和EXEC包裹这些命令。
关于性能⽅⾯的注意事项
redis-benchmark使⽤单客户端进⾏测试时⼀些可能引起性能问题的原因：
绝⼤部分常见的性能问题都是由表格中列出的原因引起的
