Redis进阶（2）——Redis数据的持久化 & CAP分布式理论（高可用性） & Redis主从搭建 & Redis的哨兵机制

引出

---

1.Redis持久化，RDB，快，但数据可能确实；
2.ADB追加，慢，数据准确，效率低，文件大；
3.分布式集群理论CAP：A(可用性) C(一致性) P(分区容灾(可用))；
4.主从搭建，静态网段，配置修改，允许访问bind 0.0.0.0，从的replicaof 172.18.12.15 6379；
5.哨兵机制，哨兵的搭建，3哨兵，奇数模式；

Redis数据的持久化

redis是一个内存数据库，当redis服务器重启，获取电脑重启，数据会丢失，我们可以将redis内存中的数据持久化保存到硬盘的文件中。

redis提供两种持久化方式:

​ RDB：快照，通过从服务器保存和持久化

​ AOF：日志，操作生成相关日志,并通过日志来恢复数据。couchDB对于数据内容,不修改,只追加,则文件本身就是日志,不会丢失数据.

IO:

bio阻塞：执行时，其他执行不了；比如system.out
nio管道：大家一起执行；比如Tomcat
aio异步：数据过一会才出现；

RDB方式(redis database数据备份文件)

RDB持久化是指在指定的时间间隔内将redis内存中的数据集快照写入磁盘，实现原理是redis服务在指定的时间间隔内先fork一个子进程，由子进程将数据集写入临时文件，写入成功后，再替换之前的文件，用二进制压缩存储，生成dump.rdb文件存放在磁盘中。

默认开启，会按照配置的指定时间将内存中的数据快照到磁盘中，创建一个dump.rdb文件，Redis启动时再恢复到内存中。

在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里,Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。

整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。

RDB工作机制

• Redis提供了RDB持久化能力，这个功能可以将Redis在内存中的数据库状态保持在磁盘里面，避免数据意外丢失。
• RDB持久化机制可以手动执行，也可以根据服务器配置选定定期执行操作，该功能可以将某一个时间点的数据快照进行保存到一个RDB文件中。

RDB优势和劣势

优势：快	劣势：数据可能有缺失
一旦采用该方式，那么你的整个Redis数据库将只包含一个文件，这对于文件备份而言是非常完美的。比如，你可能打算每个小时归档一次最近24小时的数据，同时还要每天归档一次最近30天的数据。通过这样的备份策略，一旦系统出现灾难性故障，我们可以非常容易的进行恢复。	如果你想保证数据的高可用性，即最大限度的避免数据丢失，那么RDB将不是一个很好的选择。因为系统一旦在定时持久化之前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失。
对于灾难恢复而言，RDB是非常不错的选择。因为我们可以非常轻松的将一个单独的文件压缩后再转移到其它存储介质上。	由于RDB是通过fork子进程来协助完成数据持久化工作的，因此，如果当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟。
性能最大化。对于Redis的服务进程而言，在开始持久化时，它唯一需要做的只是fork出子进程，之后再由子进程完成这些持久化的工作，这样就可以极大的避免服务进程执行IO操作了。
相比于AOF机制，如果数据集很大，RDB的启动效率会更高。

RDB常用参数

• SAVE：由主进程进行快照(snapshot)，会阻塞其他请求。
• BGSAVE：通过fork子进程进行快照，不会阻塞其他请求。background

AOF的方式（命令追加）

AOF(Append Only File)

AOF 持久化功能则提供了一种更为可靠的持久化方式。 每当 Redis 接受到会修改数据集的命令时，就会把命令追加到 AOF 文件里，当你重启 Redis 时，AOF 文件里的命令会被重新执行一次，重建数据。AOF默认是关闭的。

思想：内存每写一条，就备份一条，时间间隔是1秒钟，缺点：文件大，写操作频繁。

• 以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)，

• 只许追加文件但不可以改写文件，redis启动之初会读取该文件(aof文件)重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作

• aof保存的是appendonly.aof文件

因为AOF采用追加的方式，所以文件会越来越大，针对这个问题，新增了重写机制，就是当日志文件大到一定程度的时候，会fork出一条新进程来遍历进程内存中的数据，每条记录对应一条set语句，写到临时文件中，然后再替换到旧的日志文件（类似rdb的操作方式）。默认触发是当aof文件大小是上次重写后大小的一倍且文件大于64M时触发。

AOF优缺点

优点：数据准确	缺点：慢，文件大，效率低
默认是每秒fsync一次。这样最多丢失1秒数据	在相同的数据集下，AOF文件的大小一般会比RDB文件大。
AOF日志文件是一个纯追加的文件。就算服务器突然Crash，也不会出现日志的定位或者损坏问题	在某些fsync策略下，AOF的速度会比RDB慢。通常fsync设置为每秒一次就能获得比较高的性能，而在禁止fsync的情况下速度可以达到RDB的水平。
当AOF文件太大时，Redis会自动在后台进行重写。重写很安全，因为重写是在一个新的文件上进行，同时Redis会继续往旧的文件追加数据。
AOF把操作命令以简单易懂的格式一条接一条的保存在文件里，很容易导出来用于恢复数据。

Redis集群

CAP理论

A(可用性) C(一致性) P(分区容灾(可用))

AP,CP(最终一致性)；

P是一定要实现的，可用性一定要有；

①一致性：对于客户端的每次读操作，要么读到的是最新的数据，要么读取失败。换句话说，一致性是站在分布式系统的角度，对访问本系统的客户端的一种承诺：要么我给您返回一个错误，要么我给你返回绝对一致的最新数据，不难看出，其强调的是数据正确。

②可用性：任何客户端的请求都能得到响应数据，不会出现响应错误。换句话说，可用性是站在分布式系统的角度，对访问本系统的客户的另一种承诺：我一定会给您返回数据，不会给你返回错误，但不保证数据最新，强调的是不出错。

③分区容忍性：由于分布式系统通过网络进行通信，网络是不可靠的。当任意数量的消息丢失或延迟到达时，系统仍会继续提供服务，不会挂掉。换句话说，分区容忍性是站在分布式系统的角度，对访问本系统的客户端的再一种承诺：我会一直运行，不管我的内部出现何种数据同步问题，强调的是不挂掉。

主从搭建(Master/Slave)

主master的redis

自定义docker静态网段

[root@localhost conf]# docker network ls
NETWORK ID          NAME                DRIVER              SCOPE
480a87f5e493        bridge              bridge              local
76aceec0d608        host                host                local
79544eec7527        none                null                local
[root@localhost conf]# 

自定义docker的静态网段，关机重启，不会改变redis的ip

docker network create --driver bridge --subnet=172.18.12.0/16 --gateway=172.18.1.1 pet_docker_net

[root@localhost conf]# docker network ls
NETWORK ID          NAME                DRIVER              SCOPE
480a87f5e493        bridge              bridge              local
76aceec0d608        host                host                local
79544eec7527        none                null                local
[root@localhost conf]# docker network create --driver bridge --subnet=172.18.12.0/16 --gateway=172.18.1.1 pet_docker_net
9d04811dfd2a959c8e653cc1c0edf056f4dbd6c98af8bef0c7c23fad840cf84e
[root@localhost conf]# docker network ls
NETWORK ID          NAME                DRIVER              SCOPE
480a87f5e493        bridge              bridge              local
76aceec0d608        host                host                local
79544eec7527        none                null                local
9d04811dfd2a        pet_docker_net      bridge              local
[root@localhost conf]# 

创建文件

[root@localhost software]# mkdir -p redis/6379/conf redis/6379/data
redis/6379/log.
└── 6379
    ├── conf    
    ├── data    
    └── log

上传redis.conf到conf文件夹

创建一个日志文件

redis.log权限设置可读写

修改redis.conf文件

 75 bind 0.0.0.0

 94 protected-mode no

 303 # output for logging but daemonize, logs will be sent to /dev/null
 304 logfile "/var/log/redis.log"

允许任何人访问【核心】

保护模式关闭，因为它比较慢

日志，304 logfile “/var/log/redis.log”

:set number
gg
66gg 

附录vim文件的跳转

1.跳转到首行（文件的第一行第一列）

gg
# 输入两个小写gg

2.跳转到末行（文件的最后一行第一列）

G
#输入一个大写G

3.跳转到指定的第n行

66gg
66G
# 输入 ngg 或 nG, n 代表行号,光标会跳转到文件的第n行。例如 66gg 或 66G，光标会跳转到第66行。

4、跳转到当前行的行首、行尾

0：行首
 
$：行尾

5、左右移动

hl（小写的L）：向左移动n位
nl（小写的L）：向右移动n位

6、跳转到指定列

n + | （管道） 或者 0nl（小写的L）

参考链接：https://blog.csdn.net/Huihuizaizi/article/details/129845652

运行容器

自定义docker的静态网段，关机重启，不会改变redis的ip

docker network create --driver bridge --subnet=172.18.12.0/16 --gateway=172.18.1.1 pet_docker_net

conf位置

[root@localhost conf]# ls
redis.conf
[root@localhost conf]# pwd
/usr/local/software/6380/conf

/usr/local/software/6380/conf/redis.conf

data的位置

[root@localhost data]# pwd
/usr/local/software/6380/data

log的位置

[root@localhost log]# ls
redis.log
[root@localhost log]# pwd
/usr/local/software/6380/log
    
/usr/local/software/6380/log/redis.log

docker run
-i：以交互模式运行容器
-t：为容器重新分配一个伪输入终端
–name :容器名称
–privileged: 设置容器公开权限（默认为true）
-p :映射端口 linux端口: 容器内置端口(mysql默认端口为3306)
-v : linux挂载文件夹/文件和容器内路径的映射
-e: 容器的环境变量（设置mysql默认用户名&密码)
-d: 后台运行容器，并返回容器ID

docker run -it \
--name redis_6379_main \
--privileged \
-p 6379:6379 \
--network pet_docker_net \
--ip 172.18.12.15 \
-v /usr/local/software/6380/conf/redis.conf:/usr/local/etc/redis/redis.conf \
-v /usr/local/software/6380/data/:/data \
-v /usr/local/software/6380/log/redis.log:/var/log/redis.log \
-d redis \
/usr/local/etc/redis/redis.conf

docker run -it \
--name redis_6380 \
--privileged \
-p 6380:6379 \
--network pet_docker_net \
--ip 172.18.12.10 \
-v /usr/local/software/redis/6379/conf/redis.conf:/usr/local/etc/redis/redis.conf \
-v /usr/local/software/redis/6379/data/:/data \
-v /usr/local/software/redis/6379/log/redis.log:/var/log/redis.log \
-d redis \
/usr/local/etc/redis/redis.conf

检查日志log

检查进程是否启动

docker ps

检查日志

docker logs redis_6379

由于是挂载启动，此时查看日志采用

cat /usr/local/software/6380/log/redis.log

[root@localhost log]# docker run -it \
> --name redis_6380 \
> --privileged \
> -p 6380:6379 \
> --network pet_docker_net \
> --ip 172.18.12.10 \
> -v /usr/local/software/6380/conf/redis.conf:/usr/local/etc/redis/redis.conf \
> -v /usr/local/software/6380/data/:/data \
> -v /usr/local/software/6380/log/redis.log:/var/log/redis.log \
> -d redis \
> /usr/local/etc/redis/redis.conf
1e9bdea8560e9e1c4977978be15d8b1954ebf843e49f504acc797b49c430a668
[root@localhost log]# docker ps 
CONTAINER ID        IMAGE                COMMAND                  CREATED             STATUS              PORTS                                                      NAMES
1e9bdea8560e        redis                "docker-entrypoint..."   7 seconds ago       Up 6 seconds        0.0.0.0:6380->6379/tcp                                     redis_6380
[root@localhost log]# docker logs redis_6380
[root@localhost log]# ls
redis.log
[root@localhost log]# cat redis.log 
Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
1:M 19 Jul 2023 09:42:11.650 * Ready to accept connections
[root@localhost log]# 

测试redis

[root@localhost conf]# docker exec -it redis_6379_main bash
root@71dd1af12898:/data# redis-cli
127.0.0.1:6379> ping
PONG

放开ipv4端口

从slave的redis

从slave的文件夹

在/usr/local下创建software目录

在software目录下创建3个redis服务器以端口号命名: 6379,6380,63801

在每个文件夹下都创建data, conf, 和logs文件夹。

• data、conf和logs文件夹
• conf：存储redis配置文件
• logs: 存储redis日志文件

[root@localhost software]# mkdir -p 6380/conf 6380/data 6380/log
[root@localhost software]# ls
6380  canal
[root@localhost software]# cd 6380/log/
[root@localhost log]# pwd
/usr/local/software/6380/log
[root@localhost log]# touch redis.log
[root@localhost log]# ll
总用量 0
-rw-r--r--. 1 root root 0 7月  19 11:32 redis.log
[root@localhost log]# chmod 777 redis.log 
[root@localhost log]# ll
总用量 0
-rwxrwxrwx. 1 root root 0 7月  19 11:32 redis.log
[root@localhost log]# 

配置文件拷贝

[root@localhost log]# docker image inspect redis 

https://redis.io/docs/management/config/

[root@localhost 6380]# cd conf/
[root@localhost conf]# touch redis.conf
[root@localhost conf]# vim redis.conf 
[root@localhost conf]# cat redis.conf 
# Redis configuration file example.
#
# Note that in order to read the configuration file, Redis must be
# started with the file path as first argument:
#
# ./redis-server /path/to/redis.conf

# Note on units: when memory size is needed, it is possible to specify
# it in the usual form of 1k 5GB 4M and so forth:

配置文件结构

[root@localhost 6380]# yum -y install tree
[root@localhost 6380]# tree
.
├── conf
│   └── redis.conf
├── data
└── log
    └── redis.log

3 directories, 2 files

主从的文件夹

[root@localhost software]# ls
6380  6381  canal
[root@localhost software]# tree
.
├── 6380
│   ├── conf
│   │   └── redis.conf
│   ├── data
│   └── log
│       └── redis.log
├── 6381
│   ├── conf
│   │   └── redis.conf
│   ├── data
│   └── log
│       └── redis.log
└── canal
    └── conf
        ├── canal.properties
        └── instance.properties

10 directories, 6 files

修改从配置文件

[root@localhost ~]# docker inspect redis_6379_main | grep IPA
            "SecondaryIPAddresses": null,
            "IPAddress": "",
                    "IPAMConfig": {
                    "IPAddress": "172.18.12.15",
[root@localhost ~]# 

 479 # replicaof <masterip> <masterport>
 480 replicaof 172.18.12.15 6379
 481 slave-read-only no
     
 1256 appendonly yes

运行从的redis

docker run
-i：以交互模式运行容器
-t：为容器重新分配一个伪输入终端
–name :容器名称
–privileged: 设置容器公开权限（默认为true）
-p :映射端口 linux端口: 容器内置端口(mysql默认端口为3306)
-v : linux挂载文件夹/文件和容器内路径的映射
-e: 容器的环境变量（设置mysql默认用户名&密码)
-d: 后台运行容器，并返回容器ID

docker run -it \
--name redis_6381_slave \
--privileged \
-p 6381:6379 \
--network pet_docker_net \
--ip 172.18.12.16 \
-v /usr/local/software/6381/conf/redis.conf:/usr/local/etc/redis/redis.conf \
-v /usr/local/software/6381/data/:/data \
-v /usr/local/software/6381/log/redis.log:/var/log/redis.log \
-d redis \
/usr/local/etc/redis/redis.conf

检查日志

[root@localhost conf]# cat /usr/local/software/6381/log/redis.log

查看从redis的状态

[root@localhost conf]# docker exec -it redis_6381_slave bash
root@80b796f922eb:/data# redis-cli
127.0.0.1:6379> info replication

查看主master的状态

[root@localhost conf]# docker exec -it redis_6379_main bash
root@71dd1af12898:/data# redis-cli
127.0.0.1:6379> info replication

主从同步

哨兵机制(sentinel)

主从工作

架构

问题

如果主服务器(master)出现宕机，那么向从库写数据就会出现问题。

解决方案

智能化节点监测-哨兵模式： Redis 在 2.8 版本以后提供的哨兵（Sentinel）机制，它的作用是实现主从节点故障转移。它会监测主节点是否存活，如果发现主节点挂了，它就会选举一个从节点切换为主节点，并且把新主节点的相关信息通知给从节点和客户端。

什么是哨兵机制

Sentinel（哨岗、哨兵）是Redis的**高可用性（high availability）**解决方案：由一个或多个Sentinel实例（instance）组成的Sentinel系统（system）可以监视任意多个主服务器，以及这些主服务器属下的所有从服务器，并在被监视的主服务器进入下线状态时，自动将下线主服务器属下的某个从服务器升级为新的主服务器，然后由新的主服务器代替已下线的主服务器继续处理命令请求。

哨兵模式架构（三哨兵方式）

搭建哨兵模式(三哨兵)

redis服务的IP地址

序号	服务器名称	ip地址
1	redis_6379 (主)	172.18.12.10
2	redis_6380 (从)	172.18.12.10
3	redis_6381(从)	172.18.12.10

哨兵配置文件

每一个redis创建哨兵配置文件

文件名命名：sentinel.conf

编辑redis-sentinel.conf文件

sentinel monitor

• master-name: redis 主服务器名称
• ip: redis 主服务器的ip地址
• redis-port ： redis主服务器的端口号
• quorum: 设定了当几个哨兵判定这个节点失效后，才认为这个节点真的失效了，例如如果设置为2，则表示有两个哨兵联合判断是否失效。

• 哨兵1：跟踪redis(主)

# 所以无需担心端口重复使用
# 如果需要在单机
port 26379

# 设定密码认证
# requirepass 123456

# 配置哨兵的监控参数
# 格式：sentinel monitor    
# master-name是为这个被监控的master起的名字
# ip是被监控的master的IP或主机名。因为Docker容器之间可以使用容器名访问，所以这里写master节点的容器名
# redis-port是被监控节点所监听的端口号
# quorom设定了当几个哨兵判定这个节点失效后，才认为这个节点真的失效了
sentinel monitor redis_6379 172.18.12.10 6379 2

# 连接主节点的密码
# 格式：sentinel auth-pass  
# sentinel auth-pass local-master 123456

# master在连续多长时间无法响应PING指令后，就会主观判定节点下线，默认是30秒
# 格式：sentinel down-after-milliseconds  
sentinel down-after-milliseconds redis_6379 30000

• 哨兵2：跟踪redis(从1)

# 所以无需担心端口重复使用
# 如果需要在单机
port 26380

# 设定密码认证
# requirepass 123456

# 配置哨兵的监控参数
# 格式：sentinel monitor    
# master-name是为这个被监控的master起的名字
# ip是被监控的master的IP或主机名。因为Docker容器之间可以使用容器名访问，所以这里写master节点的容器名
# redis-port是被监控节点所监听的端口号
# quorom设定了当几个哨兵判定这个节点失效后，才认为这个节点真的失效了
sentinel monitor redis_6379 172.18.12.10 6379 2

# 连接主节点的密码
# 格式：sentinel auth-pass  
# sentinel auth-pass local-master 123456

# master在连续多长时间无法响应PING指令后，就会主观判定节点下线，默认是30秒
# 格式：sentinel down-after-milliseconds  
sentinel down-after-milliseconds redis_6379 30000

• 哨兵3： 跟踪redis(从2)

# 所以无需担心端口重复使用
# 如果需要在单机
port 26381

# 设定密码认证
# requirepass 123456

# 配置哨兵的监控参数
# 格式：sentinel monitor    
# master-name是为这个被监控的master起的名字
# ip是被监控的master的IP或主机名。因为Docker容器之间可以使用容器名访问，所以这里写master节点的容器名
# redis-port是被监控节点所监听的端口号
# quorom设定了当几个哨兵判定这个节点失效后，才认为这个节点真的失效了
sentinel monitor redis_6379 172.18.12.10 6379 2

# 连接主节点的密码
# 格式：sentinel auth-pass  
# sentinel auth-pass local-master 123456

# master在连续多长时间无法响应PING指令后，就会主观判定节点下线，默认是30秒
# 格式：sentinel down-after-milliseconds  
sentinel down-after-milliseconds redis_6379 30000

创建运行哨兵容器

创建第一个哨兵(26379)

docker run -it \
--name sentinel_26379 \
--privileged \
--network my_docker_net \
--ip 172.18.12.20 \
-p 26379:26379 \
-v /usr/local/software/redis/6379/sentinel/sentinel.conf:/data/redis-sentinel.conf \
-d redis \
redis-sentinel redis-sentinel.conf

创建第二个哨兵(26380)

docker run -it \
--name sentinel_26380 \
--privileged \
--network my_docker_net \
--ip 172.18.12.21 \
-p 26380:26380 \
-v /usr/local/software/redis/6380/sentinel/sentinel.conf:/data/redis-sentinel.conf \
-d redis \
redis-sentinel redis-sentinel.conf

创建第三个哨兵(26381)

docker run -it \
--name sentinel_26381 \
--privileged \
--network my_docker_net \
--ip 172.18.12.22 \
-p 26381:26381 \
-v /usr/local/software/redis/6381/sentinel/sentinel.conf:/data/redis-sentinel.conf \
-d redis \
redis-sentinel redis-sentinel.conf

测试哨兵

关闭master服务器(redis_6379)

模拟主服务器宕机

• 关闭主服务器(redis_6379)之前

• 关闭主服务器(redis_6379)

• 进入 容器（redis_6380)检查状态

• 在新的master中添加数据

• 重新让之前的master(redis_6379)上线

---

总结

1.Redis持久化，RDB，快，但数据可能确实；
2.ADB追加，慢，数据准确，效率低，文件大；
3.分布式集群理论CAP：A(可用性) C(一致性) P(分区容灾(可用))；
4.主从搭建，静态网段，配置修改，允许访问bind 0.0.0.0，从的replicaof 172.18.12.15 6379；
5.哨兵机制，哨兵的搭建，3哨兵，奇数模式；