文章目录

• 持久化机制与主从架构
• • RDB
  • AOF
  • 混合模式
  • 数据备份与恢复
  • 主从架构
  • redis管道
  • 哨兵架构
  • SpringBoot项目配置哨兵

持久化机制与主从架构

redis有三种持久化机制：RDB、AOF、混合模式

RDB

是redis默认的持久化机制

# 比如redis.conf文件中默认就会开启以下配置，意思是60秒内如果 有1万个key改变就会触发RDB持久化
save 900 1
save 300 10
save 60 10000

持久化的文件的文件名与文件存储路径的配置在redis.conf文件中是下面的配置

dbfilename dump.rdb
dir ./

RDB持久化的方式有两种：

• save

  这条命令在执行时是单线程的，在备份生成rdb文件时会阻塞用户的操作

• bgsave

  rdb持久化底层默认使用的是bgsave

  就重新fork一个线程来进行数据备份，不会阻塞用户的操作。在备份过程中如果用户进行了更新操作，这块数据就会被复制一份，生成该数据的副本。然后，bgsave 子进程会把这个副本数据写入 RDB 文件，而在这个过程中，主线程仍然可以直接修改原来的数据。

RDB的优点就是文件体积小、重启恢复数据快

缺点是可能会丢失一段时间的数据，因为我们不可能每秒钟去生成一个rdb文件

AOF

如果要开启AOF持久化我们需要在redis.conf文件中放开下面这一行的配置改为yes

appendonly yes

生成的aof文件名与文件生成目录的配置如下

appendfilename "appendonly.aof"
dir ./

dir这个配置项即指定rdb文件的目录也指定aof文件的目录

AOF文件的触发策略

# appendfsync always
appendfsync everysec
# appendfsync no

• always：每一次更新都会把命令持久化到aof文件中
• everysec：默认项，每秒钟持久化一次
• no：不主动进行持久化，让操作系统在需要的时候刷新数据

aof文件存储内容的格式如下所示

# 执行的原命令
set name hs# aof文件持久化内容
*3
$3
set
$4
name
$2
hs其中*3表示这个命令有三个参数：set key  value
$3表示下来来这个参数的长度为3，比如set就是3位   name是4位   hs为2位

AOF文件的优点是数据安全性更高，不会丢失很多数据

缺点是文件更大、数据恢复时间慢

AOF文件重写

aof触发文件重写的配置项的

# 其中100是百分比，达到64m就会触发一次文件重写，aof文件自上一次重写后文件大小增长了100%则再次触发重写
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

底层其实就是相当于执行一次bgrewriteaof命令

比如我现在执行很多次自增操作

127.0.0.1:6379> set number 1
OK
127.0.0.1:6379> incr number
(integer) 2
127.0.0.1:6379> incr number
(integer) 3
127.0.0.1:6379> incr number
(integer) 4
127.0.0.1:6379> incr number
(integer) 5

而aof文件中的内容如下所示

[root@VM-8-7-centos redis-5.0.3]# cat appendonly.aof 
*3
$3
set
$6
number
$1
1
*2
$4
incr
$6
number
*2
$4
incr
$6
number
*2
$4
incr
$6
number
*2
$4
incr
$6
number

此时我手动执行bgrewriteaof命令

127.0.0.1:6379> BGREWRITEAOF
Background append only file rewriting started

现在aof文件中的内容如下所示

[root@VM-8-7-centos redis-5.0.3]# cat appendonly.aof 
*3
$3
set
$6
number
$1
5

aof文件的重写其实就是结合当前内存中的数据生成命令，然后保存在appendonly.aof文件中

如果rdb和aof两种持久化都开启后，redis服务重启时会优先使用aof文件来进行数据恢复，因为这种方式数据安全性更高。

混合模式

redis4.0版本开始有混合模式，它其实本质还是aof这种方式。如果要使用混合模式，前提是aof的配置项需要开启。

开启混合模式的配置项，redis5.0的版本默认开启

aof-use-rdb-preamble yes

混合模式结合了rdb和aof两种文件的优点，在触发aof文件重写时，此时会把当前内存中的数据生成二进制文件的格式存储在appendonly.aof文件中，之后还是以之前aof文件存储的格式存储

如下所示，前面一部分是二进制内容，后面一部分还是之前那的aof文件追加格式。

[root@VM-8-7-centos redis-5.0.3]# cat appendonly.aof 
REDIS0009	redis-ver5.0.3
redis-bits󿿀򳨭eR¨used-memÀ 
𮤭preamble󿾁þ㭡mehsnumberȫ)!*2
$6
SELECT
$1
0
*3
$3
set
$5
name1
$7
hushang

其实当我们使用混合模式这种方式后，就可以不需要再单独触发rdb文件备份了，可以将redis.conf文件中的save配置项都注释掉

数据备份与恢复

我们可以利用crontab定时任务备份aof或rdb文件

在数据恢复时只是将备份的文件放到指定目录下(dir配置项目录)，然后重启redis-server即可完成数据恢复

主从架构

搭建主从架构

拿一台服务器上运行多个redis-service实例来举例

首先复制一份redis.conf文件，修改下面这几个不能重复的配置项

port 6380
pidfile /var/run/redis_6380.pid  # 把pid进程号写入pidfile配置的文件
logfile "6380.log"
dir /usr/local/redis-5.0.3/data/6380  # 指定数据存放目录

主从架构重点是配置下面的几行配置

replicaof 192.168.0.60 6379   # 从本机6379的redis实例复制数据，Redis 5.0之前使用slaveof
replica-read-only yes  # 配置从节点只读# 如果master配置的密码，那么我们在从机上也要指定密码
masterauth 

启动两个服务后，在redis-cli中可以通过info replication命令来查看主从架构是否搭建成功

全量主从复制原理

1. 主从两个节点建立socket长连接
2. 从节点向主节点发送psync命令进行数据同步
3. 主节点会生成最新的rdb文件，并且还会有一个repl buffer缓冲区
4. 把rdb文件同步给从节点
5. 从节点清空老数据并加载rdb文件内容
6. 如果在数据同步过程中，master节点有新的更新操作，这个更新操作会缓存在repl buffer中，从节点加载完rdb文件后再将repl buffer中的数据发送给从节点
7. 从节点再执行buffer中的命令
8. 之后主节点执行更新操作都会通过socket长连接同步给从节点

部分数据主从复制

如果某个时间点从节点宕机了，过一段时间后有重启了，那么这个时候我想要只是把宕机这段时间的数据进行增量复制，而不进行全量复制。过程如下

1. master节点会缓冲一部分最近执行的命令在repl backlog buffer缓冲中
2. 从节点重新和master建立连接后，从节点会向master发送一个psync(offset)命令，会携带从节点宕机时从主节点复制数据的偏移量
3. master拿到这个offset后去repl backlog buffer中找判断是否能找到
4. 如果找到了那么就从这个偏移量开始，将之后的命令同步给从节点
5. 如果找不到则进行全量备份

主从复制风暴

如果一个master节点下有很多的slave节点，为了缓解主从复制风暴(多个从节点同时复制主节点导致主节点压力过大)，可以做如下架构，让部分从节点与从节点(与主节点同步)同步数据

redis管道

redis客户端可以一次性发送多条命令给redis-service去执行，目的是减少网络传输开销。但管道不能保证多条命令的原子性，如果其中有一条命令执行失败了是不会影响到其他命令的执行，以下是一个jedis使用管道的实例

Pipeline pl = jedis.pipelined();
for (int i = 0; i < 10; i++) {pl.incr("pipelineKey");pl.set("zhuge" + i, "zhuge");//模拟管道报错// pl.setbit("zhuge", -1, true);
}
List