redis之数据安全与性能保障详解

两种持久化：

快照持久化（snapshotting）

存储所有数据到磁盘

save 60 1000stop-writes-on-bgsave-error nordbcompression yesdbfilename dump.rdb

创建快照有这么几种方法：
1，bgsave命令，会fork出一个进程
2，save命令，会造成在完成前，客户端是去响应
3，配置save项
4，Redis通过shutdown关闭时
5，当一个redis连接到另一个redis时，一般是主从复制时

注意：bgsave和save的区别：

SAVE 和 BGSAVE 两个命令都会调用 rdbSave 函数，但它们调用的方式各有不同：• SAVE 直接调用 rdbSave ，阻塞 Redis 主进程，直到保存完成为止。在主进程阻塞期间，服务器不能处理客户端的任何请求。• BGSAVE 则 fork 出一个子进程，子进程负责调用 rdbSave ，并在保存完成之后向主进程发送信号，通知保存已完成。因为 rdbSave 在子进程被调用，所以 Redis 服务器在BGSAVE 执行期间仍然可以继续处理客户端的请求。

追加文件（AOF）

存储所有执行的命令到磁盘

appendonly noappendfsync everysecno-appendfsync-on-rewrite noauto-aof-rewrite-percentage 100auto-aof-rewrite-min-size 64mb

appendfsync选项和同步频率

选项同步频率always每个redis命令都要同步到硬盘。这样会严重影响redis的速度everysec每秒执行一次同步no让操作系统来决定什么时候进行同步

但是存在一个问题，aof文件会越来越大，甚至远远大于快照文件。为了解决这个问题，可以用bgrewriteaof，这个命令和bgsave一样，会创建一个子进程来重写aof文件，移除冗余命令。跟快照持久化一样，aof也可以设置auto-aof-rewrite-percent选项和auto-aof-rewrite-min-size来自动执行bgrewriteaof。
一般推荐用everysec

无论采用哪种方式，都不足以保证数据安全。所以如果条件允许的话，最好能把数据备份到其他服务器上

redis复制

主从复制

有经验的工程师都知道复制（replication）是补课或缺的。复制可以让其他服务器拥有数据副本。redis也拥有这种能力。
非常简单：
你需要设置dir和dbfilename选项。
然后安装两个redis服务器，选择一台作为备机，修改其redis.conf

slaveof <masterip> <masterport>

，开启主redis，再开启从redis。这样你在主机上的数据就可以备份到从redis了。（从redis是不允许写入数据的，而且从reids会抛弃掉之前拥有的所有数据）
开启redis的主从复制并不需要太多的配置，不过了解其工作过程将会很有趣，也很有用。

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

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

警告：
1，redis不支持主主复制（master-master replication）。
2，从服务器会删掉所有数据。

当多个从服务器尝试连接同一个主服务器时，情况又会变得不一样

当有新的从服务器连接主服务器时主服务器的操作上表的步骤3尚未执行所有的从服务器会接收到相同的快照文件和相同的缓冲区命令上表的步骤3正在执行或已经执行完毕当主服务器完成上表的5个步骤之后，再从步骤1执行到步骤5

主从链

redis的从服务器和主服务器并没有什么特别不同的地方，因此，从服务器也可以拥有其从服务器。
但是请注意其过程：如果从服务器X拥有从服务器Y，那么当从服务器X执行步骤4时，他会断开与Y的连接，导致从服务器Y需要重连并重新同步。
当读请求的重要性远远高于写请求，那么可以创建一个由主从节点（master-slave node）组成的中间层来分担主服务器的复制工作。

redis事物

之前也介绍了事物，利用multi和exec就可以实现简单的事物。但是存在一个问题：用户没办法根据读到的数据来做决定。比如，下订单的时候，需要根据读到的商品库存量来决定是否可以下单。
为了解决这个问题，我们需要知道watch，有的时候还需要unwatch和discard命令。

非事物型流水线(管道技术)

Redis服务是一种C/S模型，提供请求－响应式协议的TCP服务，所以当客户端请求发出，服务端处理并返回结果到客户端，一般是以阻塞形式等待服务端的响应，但这在批量处理连接时延迟问题比较严重，所以Redis为了提升或弥补这个问题，引入了管道技术：可以做到服务端未及时响应的时候，客户端也可以继续发送命令请求，做到客户端和服务端互不干涉影响，服务端并最终返回所有服务端的响应，这在促进原有C/S模型交互的响应速度上有了质的提高。