Redis持久化及主从复制

RDB

Redis之所以快，其读写在内存是其中一个原因；但是因为读写在内存如果服务器宕机了数据都会消失不见，所以需要对Redis考虑持久化的问题。

RDB就是Redis数据持久化的一种方式。他是基于快照的方式，在一定的时间间隔和操作下，对当前的数据进行持久化，将文件放入当前启动目录下，默认命名为dump.rdb。

工作方式：
Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失（因为服务器突然宕机或者停电等等问题，导致最后一次快照未进行）。

根据配置文件了解一下RDB：

进入redis.conf配置文件找到快照这一栏目

（1）默认执行时机（可以根据需求对快照时机进行修改）：

900秒内redis有一次修改执行；
300秒内redis有十次修改执行；
60秒内redis有一万次修改执行；

（2）当Redis无法写入磁盘的话，直接关掉Redis的写操作

（3）保存的文件名：

（4）是否对文档进行压缩

（5）是否启用CRC64算法进行数据校验

（6）文件保存的路径：

手动触发快照持久化
（1）在命令行直接执行save指令，Redis会直接阻塞一切进行持久化操作
（2）在命令行直接执行bgsave指令，Redis在后台异步执行持久化操作
*（3）使用flushall（清除所有）和shutdown（关机）也会进行快照触发；这里注意，使用flushall后触发的快照，这个时候没有任何数据，并且Redis的持久化机制会覆盖上一个持久化文件（相当于删库并且把备份也删了），如果没有备份到另一台服务器，找回数据相当困难。

备份
先通过config get dir 查询rdb文件的目录 , 将*.rdb的文件拷贝到别的地方

恢复
将备份好的dump.rdb移动到Redis安装目录并启动就可以了

不足之处
（1）虽然Redis在fork时使用了写时拷贝技术,但是如果数据庞大时还是比较消耗性能。
（2）在备份周期在一定间隔时间做一次备份，所以如果Redis意外down掉的话，就
会丢失最后一次快照后的所有修改。

AOF

以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来（只会记录写的操作），只许追加文件但不可以改写文件，Redis启动之初会读取该文件重新构建数据，换言之，Redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

配置文件

（1）是否开启（默认情况下关闭）

（2）文件名

（3）执行机制

1）始终同步，每次Redis的写入都会立刻记入日志
2）每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。（默认选项）
3）把不主动进行同步，把同步时机交给操作系统。

（4）重写机制属性配置

重写机制
AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制,当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集.可以使用命令bgrewriteaof。

（1）Redis如何实现重写
AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)，遍历新进程的内存中数据，每条记录有一条的Set语句。重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似。

（2）何时重写
重写虽然可以节约大量磁盘空间，减少恢复时间。但是每次重写还是有一定的负担的，因此设定Redis要满足一定条件才会进行重写（具体条件看上文的配置文件；默认是比上一次重写大一倍并且大于64M时触发）。
系统载入时或者上次重写完毕时，Redis会记录此时AOF大小，设为base_size,如果Redis的AOF当前大小>= base_size +base_size*100% (默认)且当前大小>=64mb(默认)的情况下，Redis会对AOF进行重写。

不足之处
（1）比起RDB占用更多的磁盘空间
（2）恢复备份速度要慢
（3）每次读写都同步的话，有一定的性能压力。

RDB和AOF的选择
（1）官方推荐两个都启用。
（2）如果对数据不敏感（因为RDB是间隔范围内存储，AOF默认是每秒一次），可以选单独用RDB
（3）不建议单独用 AOF，因为可能会出现Bug。
（4）如果只是做纯内存缓存，可以都不用

Redis对事务的部分支持

在Redis中，也有对事务的操作；但是其对事务只是部分支持，但是Redis不像MySQL一样，Redis没有隔离级别。

操作指令：

指令	解读
MULTI	开启事务
EXEC	提交事务
DISCARD	终止事务
UNWATCH	取消对所有key的监控
WATCH key1 …	监控一个或多个key

在Redis中，开启事务后，会将接下来的命令放入到队列中，等待执行EXEC命令时，会按照放入队列的顺序从头到尾的开始执行。

那么为什么会说Redis对事务是部分支持的呢：

（1）首先我们来看支持的方面：Redis对于事务的支持是在对语法有错误的地方你执行命令后，马上就会报错，当你提交事务后也还是会报错。我们最后可以看到，在这个事务的所有指令最终都没有生效，保证了事务的原子性。

（2）反之，不支持的一面：在我们输入完指令后，incr k1返回的信息表示其进入队列而不是像上面那样直接报错；这就是“运行时错误”并非语法错误。我们可以看到，当我们提交事务后，第二到四步都正常执行了，只有第一步执行错误，所以第一步指令没有生效。这就违背了事务的一致性（要么全部成功，要么全部不成功；这个显然是部分成功，部分不成功）。所以说Redis对事务只是部分支持。

Redis对key的监控
通过watch指令可以对某个键进行监控。当开启事务后，在事务未提交之前，如果这个键的值发生了变化，那么这次事务会提交失败。

主从复制

主从复制：主机数据更新后根据配置和策略，自动同步到备用机上去；一般主机以写为主，从机以读为主。

目的
（1）读写分离，性能扩展
（2）容灾快速恢复

配置文件（改一些文件名只是便于在出错时能精准定位到文件）：
（1）拷贝多个redis.conf配置文件

（2） 开启daemonize yes、修改pidfile以及修改端口号（端口号必须改，否则会冲突）

（3）Log日志文件名字

（4）修改备份文件名dbfilename

配置原则及相关指令
（1）配从机不配主机
（2）从库的配置：slaveof 主库Ip 主库端口
（3）查看现在主从状态：info replication
（4）每次从库与主库断开连接后，都需要重新连接除非配置了redis.conf文件

实操

一主二从：
主机：

从机：

从机配置：

再次查看主从状态信息：
主机信息：

从机信息：

常见问题测试
（1）主机已有数据，从机连上是否会包含之前的数据：
1 ）主机：

2)从机：
)
3）连接上以后：

我们可以看到当从机连接上以后，主机之前的所有数据都会复制到从机上。

（2）主从机读写问题：
1）主机；读写都OK

2）从机；只可读不可写

（3）主机shutdown后，从机的状态如何：
1）主机

2）从机；一直处于等待状态

（4）主机回来后并写入，从机能否获取
1）主机

2）从机可以获取

（5）其中一台从机挂掉了然后又连上的情况：

1）主机不显示挂掉的那台从机

2）从机从新连上后；这台从机就变成了主机；不在连上之前的主机，但是数据仍有

薪火相传
该种方式像一个链表一样；一个传一个。

我们来看三台机的情况：
PC1：

PC2：

PC3：

我们可以看到：第二台机显示时从机，但是他自己又有从机。这种模式就是薪火相传。

注意：这种模式下更换主机，会清除之前的数据。需要重新建立拷贝最新的；一旦某个slave宕机，后面的slave都没法备份

反客为主：
当主机挂掉之后，手动选择一个新的主机
直接在需要转成主机的命令行上执行以下命令即可：

slaveof no one

当然这种方法不经常用；后面接触到哨兵模式，由哨兵自动投票选择一个新的主机。

Redis的发布订阅

Redis也可以做消息中间件，不过一般用于分布式缓存；消息中间件一般还是由MQ来做。这里做下简单的介绍：

订阅：

SUBSCRIBE 频道1 频道2

发布

PUBLISH 频道 内容