redis持久化

一：什么是持久化

持久化就是将数据保存到我们的硬盘中，将数据保存到硬盘上的这个过程就是持久化。redis是一个内存数据库，数据保存在内存中，但是对于内存中的数据是很容易丢失的，当redis宕机的时候，数据就会丢失，所以持久化可以有效的防止数据的丢失。

二：redis持久化的方式

redis支持两种持久化的方式：RDB和AOF

RDB：RDB其实就是把数据以快照的形式保存在磁盘上。我们可以将快照理解成把当前时刻的数据拍成一张照片保存下来。RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘。也是默认的持久化方式，这种方式是就是将内存中数据以快照的方式写入到二进制文件中,默认的文件名为dump.rdb。

AOF：AOF的通俗理解就是一种日志记录，redis会将我们所有的写操作都存放到一个日志文件中，当redis运行的时候，会将这个日志文件中的所有指令都执行一遍。

三：RDB持久化方式

RDB方式是通过把某个时刻的所有数据生成一个快照来保存，那么就有触发机制，来实现这个过程。对于RDB来说，提供了三种机制：save、bgsave、自动化。

1.save机制

该命令会阻塞当前Redis服务器，执行save命令期间，Redis不能处理其他命令，直到RDB过程完成为止。也就是当一个客户端执行save指令的时候，会将redis阻塞，其他所有的客户端都不能进行任何的命令操作redis。

2.bgsave机制

执行该命令时，Redis会在后台执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。在这个阶段，其他客户端对redis发出的命令，redis可以进行执行。

因为bgsave不会对redis进行阻塞，所以基本上 redis 内部所有的RDB操作都是采用 bgsave 命令。

3.自动化机制

自动化机制其实是通过redis的配置文件：redis.conf中的配置进行实现的。在redis的配置文件中有一下一部分内容。

每3600秒内有一次对键的修改时，就会触发一次bgsave命令

4.redis的恢复数据

当redis的目录中有dump.rdb时，只要redis启动，就会读取dump.rdb中的数据，进行数据的加载

5.RDB持久化的优缺点

优势

1.RDB文件适合用于备份和进行数据的恢复

2.当使用bgsave的时候，可以不阻塞redis。是通过创建的子进程完成的写入操作，主线程不需要进行IO流的操作

3.RDB适合进行数据的恢复，当时数据量很大的时候，比AOF速度快的多，因为AOF中存的是一个个的命令，当恢复的时候，要将命令一个个执行。

缺点

当执行持久化操作的时候，如果有新的客户端进行对键的写操作，这个操作是不会被保存成快照的，这一部分的写操作就会丢失。

四：AOF持久化方式

AOF就是将所有的执行的命令都存入到一个文件中。redis默认是关闭AOF的，我们想要使用AOF进行持久化就需要将AOF开启，需要修改redis的配置文件。

1.AOF持久化触发的时机

AOF持久化触发的时机有三种

appendfsync always：总是触发，没当执行一次写的操作就会执行一次

appendfsync everysec：每隔一秒就会执行，默认是这个时机

appendfsync no：不进行触发

查看appendonly.aof

2.AOF的优缺点

优点

1.AOF可以更好的保证数据不会丢失，因为默认是每隔一秒就执行一次，所以最多就会丢失一秒的记录。

2.AOF日志文件没有磁盘寻址的开销，写入性能高，文件不易损坏。

3.AOF日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写。

缺点

1.相比于dump.rdb文件，appendonly.aof文件更大。

2.相比于rdb，恢复数据的速度慢。

五：redis的主从关系

因为对于数据库的操作而言，查询读取数据的次数是要大于写的次数的，所以，当只有一个redis的时候，如果读的请求过多，则会响应很慢，有一部分请求会被阻塞，只有当前面请求完成之后，才会进行被阻塞的请求。这个时候配置redis主从关系就可以解决这个问题，请求过多的时候，可以去对从redis进行请求。

1.创建三台redis

为了节省资源，我们可以在一台虚拟机上创建三台redis，因为redis的运行是依赖配置文件的，随意我们只需要创建三个不同的redis配置文件就可以，并且里面的redis端口号要不同。

使用命令，在redis根目录创建一个文件夹，用来存放三个redis的配置文件。

①先创建一个文件夹，将redis的配置文件移入到文件夹中

②将配置文件重命名

③将配置文件复制两份，并重命名，修改配置文件中的端口号

④运行三台nginx，并且查看redis进程

⑤查看三台redis的关系

info replication

发现现在三台redis的角色都是master，也就是说这三台redis都是主节点，并没有任何的关系。

⑥将6379这个端口的redis设置为主节点，6380和6381两台redis设置成从节点，然后再次查看redis之间的关系

设置主节点

slaveof 主节点的ip地址 主节点的端口号

当设置6379为主节点，6380和6381为从节点之后。只有主节点可以进行读写操作，从节点只能进行读的操作。并且如果再新增一个新的从节点之后，从节点的数据与主节点的数据一直，之前有的现在也有，以后有的更会存在

注意：在主从关系中，当主节点宕机了，从节点并不会变成主节点，并且仍然不具有写的操作，还是只能进行读。当主节点恢复之后，他还是主节点，并不会因为宕机而消失主节点的身份。

六：哨兵模式

因为主从关系中，主节点宕机后，就无法进行写的操作，只有主节点恢复之后才能进行写，这样显然是缺点，不合适的。所以就出现了哨兵模式，在哨兵模式中，会新增一个哨兵角色，当主节点宕机之后，会有哨兵从从节点当中选择一个变成主节点，其他从节点则会归属到这个新的主节点下。并且当原先的主节点恢复之后，他也会变这个新的主节点的从节点。

在哨兵模式中，重要的是sentinel.conf这个配置文件，里面指定了哨兵的个数，以及主节点的i信息。

①创建一个文件，将sentinel.conf拷贝到文件夹中，并进行修改。

因为现在只有一个哨兵，所以将最后的值改为1

②启动哨兵

redis-sentinel sentinel.conf

③将原本的6379端口号的主节点停掉，查看哨兵窗口，过一段时间后，会提示之前的主节点已经被某个从节点替换

④在6380端口中查看主从关系

⑤将之前的主节点3679启动，查看主从关系

七：redis集群

使用哨兵模式虽然解决了读的问题，但是并没有解决写的问题，因为只有主节点可以进行写，从节点只能进行读。所以当写的请求量很大的时候，还是需要进行等待。因此配置redis集群就可以解决读和写的问题，多个redis主节点配置成redis集群，然后一个redis主节点可以再配置哨兵模式，这样读和写的问题就都解决了。

当配置了redis集群后，会产生16384个槽，这些槽会被平均的分配到redis的主节点上。例如有四个redis主节点形成集群，就会将16384个槽平均分配到这个四个主节点上。

第一个redis主节点：0——4096

第二个redis主节点：4097——8192

第三个redis主节点：8193——12288

第四个redis主节点：12289——16384

对所有的写入操作，会执行一种crc16算法，会产生一个数字，使用这个数字对16384进行取余得到槽位，然后槽位在那个范围之内，这个key就会存入到那个redis的主节点上。

例如set k2 3 产生的数字是86295，则取余后的槽位就是4375，则这个k2就会存入到第二个redis主节点上。

①配置集群

配置一个三主一从的集群

主节点：6370   6380   6390

从节点    6371   6381   6391

②修改redis的配置文件redis.conf

要修改端口号、ip地址、AOF必须为开、开启集群、集群的配置文件、集群的超时间

port 6370
bind 0.0.0.0
daemonize yes
appendonly yes  必须有aof持久化
# 开启集群
cluster-enabled yes             833行
# 集群的配置文件,该文件自动生成   
cluster-config-file nodes-6370.conf  841行
# 集群的超时时间
cluster-node-timeout 5000         847行

创建一个新的文件夹，里面拷贝6个配置文件，分别修改他们的配置文件

③启动全部的redis

④为启动的redis设置主从关系以及槽

指令中的1表示一个主节点只携带一个从节点，前面三个是主节点，后面上是对应主节点的从节点，并且使用这个指令的时候，必须保证redis中没有任何的数据，并且AOF是开启的。

redis-cli --cluster create --cluster-replicas 1 192.168.116.29:6370 192.168.116.29:6380 192.168.116.29:6390  192.168.116.29:6371  192.168.116.29:6381 192.168.116.29:6391

⑤开启客户端，执行set指令，查看key存放到那个主节点上

redis-cli -c -h 127.0.0.1 -p 6370

执行之后会发现，crc16算法返回的值是12706，使用12706对16384取余获得的槽位是12706

6370：0-5461

6380：5462-10923

6390：10924-16394

12706在6390拥有的槽位里面，所以会给6390这个主节点，并且跳进6390这个端口

继续set k2 2 crc16算法返回的值是449,449对16384取余获取的槽位是449，所以就存在6370这个端口上，并且调回6370这个端口。