【速成Redis】04 Redis 概念扫盲：事务、持久化、主从复制、哨兵模式

redis的事务和我们之前学习的关系型数据库的事务是不太一样。

在关系型数据库中，事务是一个原子操作，要么全部执行成功，要么全部执行失败。

而在redis中，事务并不能保证所有命令都会执行成功。
redis所支持的支持事务，也就是可以在一次请求中执行多个命令，reids中的事务主要通过MULTI和EXEC实现的。

MULTI命令用来开启一个事务。事务开启后，所有命令会被放入一个队列中，最后通过一个EXEC命令来执行事务中的所有命令。

2.redis可以保证以下3点

1.在发送EXEC命令之前，所有命令都会被放入到一个队列中缓存起来，不会立即执行

2.在收到EXEC命令之后，事务开始执行，事务中任何一个命令执行失败，其他命令依然会回执行。

3.在事务执行过程中，其他客户端提交的命令请求，并不会被插入到事务的执行命令序列中。

3.实操

1.MUTLI开启事务、EXEC提交事务

2.验证事务的特性：

先创建三个新的键：k3、k4、k5

开启事务并且，让其自增，很显然k4的value无法解析为数字，无法自增

结束事务，开始执行命令：

可以看到第二个命令执行失败，别的键已经自增，k4没有变化

二、持久化

持久化是redis一个非常重要的功能，因为redis是基于内存的数据库，如果没有持久化的话，一旦服务器重启或者断电，那么之前所有的数据都会丢失。

redis持久化主要有两种方式：

1.RDB

是指在指定时间间隔内，将内存中的数据快照写入磁盘，它是某一个时间点上数据的完整副本。

- 可以通过使用配置文件中的save参数来配置：

如图，找到redis.windows.conf配置文件

把sava命令修改

save x y：在x秒时候至少y个键被修改进行一次快照

（根据自己电脑的配置和使用情况修改）

带着新配置文件启动redis服务

在客户端可以检查配置

- 通过手工save命令

除了用配置文件触发快照之外，还可以使用save命令来手工触发快照。

依旧是同一个配置文件，这里是快照储存路径。
执行完修改之后，手工save。

在快照保存处可以看到rdb文件了。

- 快照文件缺点：

**如果服务机器在最后一次快照之后宕机了，那么最后一次快照之后的修改内容都会丢失掉。**所以RDB更适合用来做备份，比如可以每天凌晨时，通过crontab来执行一次save 命令，然后将快照文件备份到其他地方，保证数据安全。

在生产环境中，我们为redis开辟的内存区域都比较大，**那么内存中的数据同步到硬盘这个过程，就会持续比较长的时间，这段时间redis处于一个阻塞状态，**显然是不行的，这段时间内redis都是处于一个阻塞状态，不能接受任何请求。

**于是redis提供了一个bgsave的命令，这个命令会单独创建一个子进程，来负责内存数据写入硬盘。**这时候主进程就可以接受请求了，但这个过程中还是会有一定的性能损耗。因为fork一个子进程是需要时间的，这段时间redis还是不能处理任何请求，无法做到秒级快照。

2.AOF

- 原理：

为了解决快照文件的这个问题，redis提供了另一种文件持久化方式：AOF(字面意思是追加文件)，**它的原理是在执行写命令时，不仅会将命令写入到内存中，也会讲命令写到一个文件中，这个文件就是AOF文件。**它会以日志形式记录整个写操作，当redis重启时，它就会重新通过AOF文件中的命令，来在内存中重建整个数据库内容。

- 开启AOF的方式：

如图，依旧是那个配置文件，把appendonly后的no改为yes

三、主从复制

主从复制是指将一台redis服务器节点复制到另一台redis服务器。

也叫主节点、从节点：

一个主节点可以有多个从节点，而一个从节点只可以有一个主节点。
核心作用：主节点的变化能自动同步到从节点上。

数据复制是单向的，只能由主节点到从节点。一般来说，主节点负责写操作，从节点负责读操作。主节点会将自己的数据变化，通过异步的方式发送给从节点，从节点接收到主节点的数据之后，更新自己的数据，这样就达到了数据一致的目的。

实际动手配置主从复制：主节点不需要修改任何配置，要修改的是从节点的配置。

命令配置方式有两种：一种是通过命令行执行命令。

slaveof方式指定主节点的ip和端口，这种方式不常用，了解即可，

另一种是通过配置文件（常用），实操过多这里不着重介绍。该篇主要扫盲，了解什么是主从复制。

四、哨兵模式

导入：

我们可以通过主从复制，为一个主节点，配置两个从节点，形成一主两从的redis集群，实现了一定程度上的高可用。相比单节点的redis来说有了很大的提升。

但是这个集群还是有一定问题的，主节点宕机了，我们还是需要手工去把另一台从节点提升为主节点，还是要人工干预，不是真正的高可用。

有什么方法可以实现自动的故障转移呢？这就是redis哨兵模式！

哨兵会以一个独立的进程，运行在redis集群中，用来监控redis的各个节点是否运行正常，主要用来执行下面几个功能：

**1.监控：**通过不断地发送通知，检查redis节点是否正常

**2.通知：**如果发现某个节点出问题了，哨兵就会通过发布订阅模式，来通知其他节点

**3.自动故障转移：**当主节点不能正常工作时，哨兵就会开启一个自动故障转移的操作，它会将一个从节点升级为一个新的主节点。然后再将其他的从节点指向新的主节点。

ps：哨兵本身也是一个进程，它自己也会有单节点故障的问题.

所以一般在实际的生产环境，会使用三个哨兵节点保证高可用，这三个哨兵节点会通过选举方式，选出领导者，然后由领导者来监控其他节点。如果领导者挂了，那么其他哨兵节点会重新选举出一个领导者，这样就可以保证哨兵节点的高可用了。