Redis 数据安全与性能保障

数据安全与性能保障

·将数据持久化至硬盘
·将数据复制至其他机器
·处理系统故障
·reids事务
·非实物型流水线
·诊断性能问题

持久化选项：

共享选项，这个选项决定了快照文件和AOF文件的保存位置
dir ./

1. 快照(snapshotting)

快照持久化选项：
save 60 1000
stop-write-on-bgsave-error no
rdbcompression yes
dbfilename dump.rdb

创建快照的方法：
·客户端可以通过向redis发送BGSAVE命令来创建一个快照。Redis会调用fork来创建一个子进程，然后子进程负责将快照写入硬盘，而父进程则继续处理命令请求
·客户端还可以通过向Redis发送save命令来创建一个快照，接到save命令的redis服务器在快照创建完毕之前将不再相应任何其他命令，save命令并不常用，我们通常只会在没有足够内存区执行bgsave的情况下，又或者即使等待持久化操作执行完毕也无所谓的情况下，才会使用这个命令
·如果用户设置了save配置选项，比如save 60 1000，那么从redis最近一次创建快照之后开始算起，当“60秒之内有10000次写入”，这个条件被满足时，Redis就会自动触发bgsave命令，如果用户设置了多个save配置选项，那么当任意一个save配置选择所设置的条件被满足时，redis就会触发一次bgsave
·当redis通过shutdown命令接收到关闭服务器的请求时，或者接收到标准的term信号时，会执行一个save命令，阻塞所有客户端，不在执行客户端发送的任何命令，并在save命令执行完毕之后关闭服务器
·当一个redis服务器连接另一个redis服务器，并向对方发送sync命令来开始一个复制操作的时候，如果主服务器目前没有执行bgsave操作，或者主服务器并非刚刚执行完bgsave操作，那么主服务器就会执行basave命令，

使用快照持久化的场景：
·开发服务器上面，考虑尽可能降低快照持久化带来的资源消耗，设置save 900 1 这一条规则。如果服务器距离上此成功超过900秒，并且在此期间执行了至少一次写入操作，那么redis就会自动开始一次i新的bgsave操作。
·对日志进行聚合计算。在对日志文件进行聚合计算或者对页面浏览量进行分析的时候，我们唯一需要考虑的就是，如果redis因为崩溃而未能成功创建新的快照，那么我们能够承受丢失多长事件以内产生的新数据。
·大数据，当redis存储数十个GB时，为了防止redis因为创建子进程而出现停顿，我们可以考虑关闭自动保存，转而通过手动发送bgsave或save来进行持久化。手动发送bgsave以用会引起停顿，唯一不同的是用户可以通过手动发送bgsave命令来控制停顿出现的事件。

2. 只追加文件(append-only file,AOF)

AOF持久化选择appendonly no
appendfsync everysec
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

AOF持久化将被执行的写命令写道AOF文件的末尾，从此来记录数据发生的变化。因此，redis只要从头到尾重新执行一次AOF文件包含的所有写命令，就可以恢复AOF文件所记录的数据集。AOF持久化可以通过设置代码清单 appendonly yes配置选项来打开。
appendfsync配置选项对AOF文件的同步频率的影响。
always 每个reids写命令都要同步写入硬盘，这样做会严重降低redis的速度
everysec 每秒执行一次同步，显式地将多个写命令同步到磁盘
no 让操作系统来决定应该何时进行同步

**固态硬盘和appendfsync always 使用固态硬盘的用户谨慎使用always选项，因为这个选项让reids每次值写入一个命令，而不是像其他选项那样一次写入多个命令。这样不断的写入少量数据的做法有可能会引发严重的写入放大（write amplification)问题，在某些情况下甚至会将固态硬盘的寿命从原来的几年降低到几个月
为了兼顾数据安全和写入性能，用户可以考虑使用everysec选项，让reids以每秒一次的频率对AOF文件进行同步。redis每秒同步一次AOF文件时的性能和不适用任何持久化特性时的性能相差无几。可以保证即使系统崩溃，用户也最多指挥丢失一秒之内产生的数据，当硬盘忙于写入操作的时候，reids还会优雅地放慢自己的速度以便适应硬盘的最大写入速度。
使用appendfsync no选项，那么redis将不对AOF文件执行任何显式的同步操作，而是由操作系统决定。这个选项一般情况下不会对reids性能带来影响。但系统崩溃将导致使用这种选项的redis服务器丢失不定数量的数据。另外如果用户硬盘处理写入操作速度不够快的话，那么当缓冲区被等待写入硬盘的数据填满时，redis的写入操作将被阻塞。并导致redis处理命令请求速度变慢。一般不推荐使用no

2.1 重写/压缩AOF文件

redis会不断地将被执行的写命令记录到AOF文件里面，所以随着reids不断运行，AOF文件不断增加，redis重启之后需要重新执行AOF文件，如果AOF文件过大，恢复时间过长。
为了解决AOF文件不断增加的问题，用户可以向redis发送BGREWRITEAOF命令，这个命令会通过移除AOF文件中的冗余命令来重写(rewrite)AOF文件，使AOF文件的提交变得尽可能小。BGREWRITEAOF的工作原理和BGSAVE创建快照的工作原理非常相似。删除一个体积达到数十GB大的旧AOF文件可能会导致操作系统hang住数秒

无论使用AOF持久化，还是快照持久化，将数据持久化到硬盘上都是非常有必要的，但处理进行持久化之外， 用户还必须对持久化所得的文件进行备份(最好备份到多个不同地方)，这样才能尽量避免数据丢失事故发送。如果条件允许的话，最好能将快照文件和最新重写的AOF文件备份到不同的服务器上面。
通过使用AOF持久化或者快照持久化，用户可以在系统重启或者崩溃的情况下仍然保留数据，随着负载量上升。或者数据完整性变得越来越重要时，用户可能需要使用复制特性。

复制：

对Redis的复制相关选项进行配置：

主服务器配置： dir, dbfilename 选项，并且这两个选项所指示的路径和文件对于redis进程来说都是可写的(writeable)
开启从服务器所必须的选项只有slaveof一个，如果用户在启动redis时候指定了一个包含slaveof host port选项的配置文件，那么redis服务器将根据指定的IP地址和端口号来连接主服务器。对于一个正在运行的redis服务器。用户可以通过发送slaveof no one 命令来让服务器终止复制操作，也可以通过发送slaveof host port命令来让服务器开始复制一个新的主服务器

Redis复制的启动过程:

Redis在复制进行期间也会尽可能地处理接收到的命令请求，单实如果主从服务器之间的网络带宽不足，或者主服务器没有足够的内存来创建子进程和创建记录写命令的缓冲区，那么redis处理命令请求的效率就会受到影响。在实际中最好还是让主服务器只是用50%-65%的内存，留下30%-45%的内存用于执行BGSAVE命令和创建记录写命令的缓冲区

**从服务器在进行同步时，会清空自己的所有数据

**Redis不支持主主复制

当多个从服务器尝试连接同一个主服务器的时候，就会出现上图的两种情况中的其中一种

主从链

当读请求的重要性明显高于写请求的中华药性，并未读请求的数量远远超出一台Redis服务器可以处理的范围时，用户就需要添加新的从服务器来处理读请求。随着负载不断上升，主服务器可能会无法快速地更新所有从服务器，或者因为重新连接和重新同步从服务器而导致系统超载，为了缓解这个问题，用户可以创建一个由Redis主从节点组成的中间层来分担主服务器的复制工作：

为了将数据保存到多台机器上面，用户首先需要为主服务器设置多个从服务器，然后对每个从服务器设置appendonly yes 选项和 appendfsync everysec 选项(如果有需要的话，也可以对主服务器进行相同的设置)，这样的话，用户就可以让多台服务器以每秒一次的频率将数据同步到硬盘上了，但这还只是第一步，因为用户还必须等待主服务器发送的写命令到达从服务器，并且在执行后续操作之前，检查数据是否已经被同步到了硬盘里面

检验硬盘写入

为了验证主服务器是否已经将写数据发送至从服务器，和用户需要在向主服务器写入真正的数据之后，再向主服务器写入一个唯一的虚构值(unique dummy value)，然后通过检查虚构值是否存在于从服务器来判断写数据是否已经到达从服务器。

判断数据是否已经被保存到磁盘里面，对于每秒同步一次AOF文件的redis服务器来说用户总是可以通过等待1秒来确保数据已经被保存到磁盘里面。更节约时间的做法是，检查INFO命令输出结果中aof_pending_bio_fsync属性的值是否为0， 如果是的话那么就表示服务器已经将已知的所有数据都保存到磁盘里面了。

处理系统故障

验证快照文件和AOF文件

无论是快照持久化还是AOF持久化，都提供了再遇到系统故障时进行数据恢复的工具。Redis提供了两个命令行程序 redis-check-aof 和 redis-check-dump, 他们可以在系统故障发生之后，检查AOF文件和快照文件的状态，并在有需要的情况下对文件进行修复

如果用户在运行reids-check-aof程序时给定了--fix参数，那么程序将对AOF文件进行修复。程序修复AOF文件的方法非常简单：它会扫描给定的AOF文件，寻找不正确或者不完整的命令，当发现第一个出错命令的时候，程序删除出错的命令以及位于出错命令之后的所有命令，只保留那些位于出错命令之前的正确命令。在大多数情况下，被删除的都是AOF文件末尾的不完整的写命令。

更换故障主服务器

假设 A、B两台机器运行Redis，其中机器A的reids为主服务器，而机器B的reids为从服务器，A挂了，之后想新加C作为新的主服务器。

步骤：

1、在机器B发送一个SAVE命令，让他创建一个新的快照文件

2、接着将这个快照文件发送给机器C，并在机器C上面启动Redis

3、让机器B成为机器C的从服务器。

另一种创建新的主服务器的方法，就是将从服务器升级(turn)为主服务器，并为升级后的主服务器创建从服务器。

Redis Sentinel ， Redis Sentinel 可以监视指定的Redis主服务器及其属下的从服务器，并在主服务器下线时自动进行故障转移(failover)。

Redis 事务

Redis的事务以特殊命令MULTI为开始，之后跟着用户传入的多个命令，最后以EXEC结束。但是由于这种简单的事务在EXEC命令被调用之前不会执行任何实际操作，所以用户将没办法根据读取到的数据来做决定。