【速成Redis】04 Redis 概念扫盲：事务、持久化、主从复制、哨兵模式
前言：
前三篇如下：
【速成Redis】01 Redis简介及windows上如何安装redis-CSDN博客
【速成Redis】02 Redis 五大基本数据类型常用命令-CSDN博客
【速成Redis】03 Redis 五大高级数据结构介绍及其常用命令 | 消息队列、地理空间、HyperLogLog、BitMap、BitField-CSDN博客
该篇04是速成系列的完结篇，主要对redis一些重要概念进行扫盲性认知，如事务、持久化、主从复制、哨兵模式。 道阻且长，学完这4篇只能称得上是刚入门redis。剩下还有很多路要走。
目录
一、redis 事务
1.认知：不是传统的事务
2.redis可以保证以下3点
3.实操
二、持久化
1.RDB
- 可以通过使用配置文件中的save参数来配置：
- 通过手工save命令
- 快照文件缺点：
2.AOF
- 原理：
- 开启AOF的方式：
三、主从复制
四、哨兵模式
一、redis 事务
1.认知：不是传统的事务
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：哨兵本身也是一个进程，它自己也会有单节点故障的问题.
所以一般在实际的生产环境，会使用三个哨兵节点保证高可用，这三个哨兵节点会通过选举方式，选出领导者，然后由领导者来监控其他节点。如果领导者挂了，那么其他哨兵节点会重新选举出一个领导者，这样就可以保证哨兵节点的高可用了。