Redis数据安全

一. Redis 数据结构(字符串，列表，集合，有序集合，发布订阅)实际用法不过多描述。

• Redis 支持数据的持久化（包括 AOF 和 RDB 两种模式），可以将内存中的数据保存在磁盘中，重启的时候可以再次加载进行使用，性能与可靠性兼顾；
• Redis 不是仅仅支持简单的 Key-Value类型的数据，还支持字符串、列表、集合、散列表、有序集合数据结构的存储，这一优势使 Redis 适用于更广泛的应用场景；
• Redis 支持数据的备份，即 Master-Slave 模式，Master 故障时，对应的 Slave 将通过选举升主，保障可用性；
• Redis 主进程是单线程工作，因此，Redis 的所有操作都是原子性的，即操作要么成功执行要么失败完全不执行。单个操作是原子性的。多个操作也支持事务，即原子性；
• Redis 性能优越，读的速度达110000次/s，写的速度达81000次/s。
• Redis 还支持 Publish/Subscribe

接下来详细总结下数据方面的知识。

二. Redis 数据安全与性能保障

1. 持久化

一种是快照，它可以将某一时刻的所有数据写入硬盘里。另一种是只追加文件(AOF), 它会在执行写命令时，将被执行的写命令复制到硬盘里。这两种持久化方法既可以同时使用，又可以单独使用。在某些情况下甚至两种都不能用，具体选择哪种持久化方法需要用户的数据以及应用来决定。

将内存中的数据存储到硬盘的一个主要原因是为了在之后重用数据，或者为了防止系统故障而将数据备份到一个远程位置。另外，存储到Redis里面的数据有可能是经过长时间计算得出的，或者有程序正在使用Redis存储的数据结构进行计算，所以用户会希望自己可以将这些数据存储起来以备后用。这样就不必重新计算了。对于一些Redis应用来说，"计算"可能只是简单地将另一个数据库的数据复制到Redis里面。但对于另外一些Redis应用来说，Redis存储的数据可能是根据数十亿行日志进行聚合分析得出的结果。

// 快照持久化 的相关设置
save 60 1000
stop-writes-on-bgsave-error no
rdbcompression yes
dbfilename dump.rdb

// AOF持久化 的相关设置
appendonly no
appendfsync everysec
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

// 快照和AOF保存的位置
dir ./

1.1 快照持久化

Redis 可以通过创建快照来获得存储在内存的数据在某个时间点的副本。在创建快照之后，用户可以对快照进行备份，可以将快照复制到其他服务器从而创建具有相同数据的服务器副本，还可以将快照留在原地以便重启服务器时使用。

根据配置，快照将被写入dbfilename 选项指定的文件里面，并存储在dir 选项指定的路径上面。如果在新的快照文件创建完毕之前，Redis、系统和或者硬盘这三者之中的任意一个崩溃了，那么Redis将丢失最近一次创建快照之后写入的所有数据。

举个栗子，假设Redis目前在内存里存储了10G的数据，上一个快照是在下午2:35开始创建的，并且已经创建成功。下午3:06时，Redis又开始创建新的快照，并且在3:08快照文件创建完毕之前，有35个键进行了更新。如果下午3:06至下午3:08期间，系统发生崩溃，导致Redis无法完成新快照的创建工作，那么Redis将丢失下午2:35之后写入的所有数据。另一方面，如果系统恰好在新的快照创建完毕之后崩溃，那么Redis将只丢失35个键的更新数据。

创建快照的办法有以下几种：

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

在只使用快照持久化来保存数据时，一定要记住：如果系统真的发生崩溃，用户将丢失最近一次生成快照之后更改的所有数据。因此，快照持久化只适用于那些即使丢失一部分数据也不会造成问题的应用程序，而不能接受这种损失的应用程序则可以使用AOF持久化，接下来介绍下AOF。

1.2  AOF持久化

简单来说，AOF持久化会将执行的写命令写到AOF文件末尾，以此来记录数据发生的变化。因此，Redis只要从头到尾执行一次AOF文件包含的所有写命令，就可以恢复AOF文件所记录的数据集。为了兼顾数据安全和写入性能，用户可以考虑appendfsync everysec 选项，让Redis以每秒一次的频率对AOF文件进行同步。Redis每秒同步一次AOF文件时的性能和不适用任何持久化操作特性时的性能相差无几。当硬盘忙于写入操作的时候，Redis还会优雅的放慢自己的速度以便适应硬盘的最大写入速度。那么问题来了，随着Redis的运行，AOF文件的体积不断增大，极端情况下，AOF文件可能用光硬盘的所有可用空间。另一问题，因为Redis重启之后需要通过重新执行AOF文件记录的所有写命令来还原数据集，所以如果AOF文件体积非常大，还原操作执行的时间就可能会很长。那么可定有解决方案，具体参数设置这里不分析。

2. 复制

2.1   主从配置

对于高负载的应用程序，复制是不可或缺的。复制可以让其他服务器拥有一个不断地更新的数据副本，从而使得拥有数据副本的服务器可以处理客户端发送的读请求。关系数据库通常会使用一个主服务器向多个从服务器发送更新，并使用从服务器来处理所有读请求。Redis也采用同样的方法来实现自己的复制特性，并将其用作扩展性能的一种手段。

主从配置不多说，来说说主从之间连接发生了什么：

从服务器连接主服务器时的步骤

步骤	主服务器操作	从服务器操作
1	等待命令进入......	连接主服务器, 发送sync命令
2	开始执行 BGSAVE 命令，使用缓冲区记录所有写命令	根据配置选项来决定是继续使用现有的数据来处理客户端命令请求，还是向发送命令的客户端返回错误
3	BGSAVE  命令执行完毕，向从服务器发送快照文件，并在发送期间继续使用缓冲区来记录被执行的写命令	丢弃所有旧数据，开始载入主服务器发来的快照文件
4	快照文件发送完毕，开始向从服务器发送存储在缓冲区里面的写命令	完成对快照文件的解释操作，像往常一样接受命令请求
5	缓冲区存储的写命令发送完毕，从现在开始，每执行一个写命令，就向从服务器发送相同的写命令	执行主服务器发来的所有存储在缓冲区里面的写命令；并从现在开始，接收并执行主服务器传来的每个写命令。

以上过程，Redis在复制进行期间尽可能的处理接收到的命令请求，但是，如果主从服务器之间网络带宽不足，或者主服务器没有足够的内存来创建子进程和创建记录写命令的缓冲区，那么效率大大受影响。因此，尽管这并不是必须的，实际中最好还是让主服务器只适用50%~65%的内存，留下的用于执行BGSAVE命令和创建记录写命令的缓冲区。

设置从服务器的步骤非常简单，用户既可以配置选项SLAVEOF host port 来将一个Redis服务器设置为从服务器，又可以通过向运行中的Redis服务区发送SLAVEOF命令来将其设置为从服务器。如果用户使用的是SLAVEOF配置选项，那么Redis在启动时首先会载入当前可用的任何快照文件或者AOF文件，然后连接主服务器并执行上表复制过程。如果用户使用的是SLAVEOF命令，那么Redis会立即尝试连接主服务器，并在连接成功之后，开始上表复制过程。(Redis不支持主主配置)

2.2 主从链

不难发现，创建多个从服务器可能造成网络不可用——当复制需要通过互联网进行或者需要在不同数据中心之间进行时，尤为如此。因为Redis的主服务器和从服务器并没有特别不同的地方，所以从服务器也可以拥有自己的从服务器，并由此形成主从链(类似二叉树的形状)