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

已于 2023-07-24 16:24:51 修改
阅读量644 收藏 1
点赞数
分类专栏： Java开发专区 运维技术专区 # Redis 文章标签： redis 分布式 数据库 运维
于 2023-07-20 12:52:56 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/Pireley/article/details/131827528
版权

目录

引出

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地址
1redis_6379 (主)172.18.12.10
2redis_6380 (从)172.18.12.10
3redis_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> <ip> <redis-port> <quorum>
# master-name是为这个被监控的master起的名字
# ip是被监控的master的IP或主机名。因为Docker容器之间可以使用容器名访问，所以这里写master节点的容器名
# redis-port是被监控节点所监听的端口号
# quorom设定了当几个哨兵判定这个节点失效后，才认为这个节点真的失效了
sentinel monitor redis_6379 172.18.12.10 6379 2

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

# master在连续多长时间无法响应PING指令后，就会主观判定节点下线，默认是30秒
# 格式：sentinel down-after-milliseconds <master-name> <milliseconds>
sentinel down-after-milliseconds redis_6379 30000
  • 哨兵2：跟踪redis(从1)
# 所以无需担心端口重复使用
# 如果需要在单机
port 26380

# 设定密码认证
# requirepass 123456

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

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

# master在连续多长时间无法响应PING指令后，就会主观判定节点下线，默认是30秒
# 格式：sentinel down-after-milliseconds <master-name> <milliseconds>
sentinel down-after-milliseconds redis_6379 30000
  • 哨兵3： 跟踪redis(从2)
# 所以无需担心端口重复使用
# 如果需要在单机
port 26381

# 设定密码认证
# requirepass 123456

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

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

# master在连续多长时间无法响应PING指令后，就会主观判定节点下线，默认是30秒
# 格式：sentinel down-after-milliseconds <master-name> <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哨兵，奇数模式；

Perley620
关注
  • 0
    点赞
  • 踩
  • 1
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
专栏目录
Redis高级特性解析：持久化、主从复制与哨兵机制全面探讨
12-14
Redis，作为一个高性能的键值对数据库，广泛应用于缓存、消息队列等场景。本文详细探讨了Redis的三大高级特性：持久化、主从复制和哨兵机制。首先，我们探讨了Redis的两种持久化方式：RDB和AOF。RDB通过定期生成数据快照来实现数据的持久化，而AOF则记录每个写操作，提供更强的数据安全性。然而，AOF由于记录每次操作，可能会导致文件体积较大，因此Redis提供了AOF重写技术来优化这个问题。 接着，文章分析了Redis的主从复制机制，它提供了数据的高可用性和读取性能的提升。在主从架构中，数据从主节点同步到从节点，从节点可以接受读请求，分担主节点负载。 最后，讨论了哨兵机制，这是一种用于监控主从集群并在主节点故障时自动进行故障转移的机制。哨兵通过监控主从节点的健康状态，自动选举新的主节点，确保系统的高可用性。
java cap_【Java】分布式CAP原则
weixin_29603489的博客
02-12 3824
CAP原则介绍CAP原则又称CAP定理，指的是在一个分布式系统中，一致性(Consistency)、可用性(Availability)、分区容错性(Partition tolerance)。CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。CAP的三个指标一致性(Consistency)“all nodes see the same data at the same time”,...
七、redis中CAP问题解决方案-Paxos理论过半通过
不吃_花椒的博客
11-03 1260
导读 前面文章【一、深入理解redis之需要掌握的知识点 】中，我们对redis需要学习的内容框架进行了一个梳理。 【二、redis中String和List两种数据类型和应用场景 】、【二、redis中Hash、Set、SortedSet应用场景 】两篇文章我们对redis中String、List、Hash、Set、SortedSet五种数据类型做了一下讲解，并且对他们各自的应用场景进行了介绍。 【三、redis数据存储之跳跃表（SKIP LIST） 】深入学习了支撑SortedSet排序背后的数据结构，跳
Redis面试题三--Redis哨兵、持久化、主从、手撕LRU
weixin_44117767的博客
11-14 1149
1.为啥Redis那么快么？ 我们可以先看一下关系型数据库跟Redis本质上的区别。 Redis采用的是基于内存的采用的是单进程单线程模型的 KV 数据库，由C语言编写，官方提供的数据是可以达到100000+的QPS（每秒内查询次数）。 完全基于内存，绝大部分请求是纯粹的内存操作，非常快速。它的，数据存在内存中，类似于HashMap，HashMap的优势就是查找和操作的时间复杂度都是O(1)； ...
redis_day03
纸鸢栀年°的博客
09-06 310
redis_day02回顾 五大数据类型及应用场景 类型 特点 使用场景 string 简单key-value类型，value可为字符串和数字 常规计数（微博数, 粉丝数等功能） hash 是一个string类型的field和value的映射表，hash特别适合用于存储对象 存储部分可能需要变更的数据（比如用户信息） list 有序可重复列表 关注列表，粉丝列表，消息队列等...
Redis哨兵、持久化、主从
weixin_41563161的博客
04-09 408
Redis哨兵、持久化、主从 1 为啥Redis那么快 2 单线程的，我们现在服务器都是多核的，那不是很浪费？ 3 Redis cluster 4他们之间是怎么进行数据交互的？以及Redis是怎么进行持久化的？Redis数据都在内存中，一断电或者重启不就木有了嘛？ 那这两种机制各自优缺点是啥？ 5 主从之间的数据怎么同步的么？ ...
《分布式缓存（一）- Redis的持久化》
小霸王的博客
05-25 928
分布式缓存
redis高可用-哨兵模式搭建(1主2从3哨兵)
qq_39839075的博客
04-06 1781
先下载redis单机版安装包，建立一个/opt/redis_sentinel目录，将tar.gz包上传到该目录。然后进入解压目录的src目录，输入如下命令执行编译。
Redis主从复制、持久化、哨兵
01-07
（一）Redis集群的主从复制 概念 主从备份，防止主机宕机 ...redis 是一个支持持久化的内存数据库，也就是说 redis 需要经常将内存中的数据同步到磁盘来保证持久化.redis 支持两种持久化方式，一种是 Snapsho
Redis 高可用之”持久化”
01-07
持久化是最简单的高可用方法(有时甚至不被归为高可用手段)，主要作用是数据备份，即将数据存储在硬盘，保证数据不会因进程退出而丢失。 复制： 复制是高可用Redis的基础，哨兵和集群都是在复制的基础上实现高可用的...
浅谈redis内存数据的持久化方式
01-21
本文介绍Redis所支持的两种数据持久化方式。 二、Redis数据持久化 Redis支持两种数据持久化方式：RDB方式和AOF方式。前者会根据配置的规则定时将内存中的数据持久化到硬盘上，后者则是在每次执行写
Redis持久化、主从与哨兵架构详解.pdf
03-18
主要介绍Redis持久化、主从与哨兵架构详解，详细具体，可操作性好！
【Redis】第4讲 分布式数据库CAP原理
a272329874a的博客
09-22 82
分区是常态，不可避免，三者不可共存可用性和一致性是对立的一致性高，可用性低一致性低，可用性高因此，根据CAP原理将NoSQL数据库分成了满足CA原则，满足CP原则和满足AP原则三大类。CA：单点集群，满足一致性，可用性的系统，通常在可扩展性上不太强大。CP：满足一致性，分区容忍性的系统，通常性能不是特别高。AP：满足可用性，分区容忍性的系统，通常可能对一致性要求低一些。
Redis主从、哨兵、持久化
pengwenrui的博客
06-21 367
主从复制：1 Master可以拥有多个slave2 多个slave可以连接同一个master，还可以连接到其他的slave3 主从复制是不会阻塞master的，在同步数据时，master可以继续的处理client请求4 提供系统的伸缩性主从复制的过程：1 slave与master建立连接，发送sync同步命令2 master会开启一个后台的进程，将数据库快照（dump.RDB文件）全量保存到文件中...
redis主从持久化配置之哨兵
cm777的博客
12-31 332
上一篇redis主从持久化配置：https://blog.csdn.net/cm777/article/details/111949950 本篇是继《redis主从持久化配置》的续篇 环境同之，只单单编写哨兵 先来看下，现在的redis容器有哪几个 其中端口为6379的是主节点，6380、6381分别是从节点，端口为26379、26380的分别是两个哨兵 再看一下文件夹目录 上面容器的配置文件都存放在对应的目录里 下面是正文 第一步、先建立好两个哨兵的配置文件的存放目录 分别是上图
redis的CAP理论简单说明
weixin_34106122的博客
01-25 627
CAP理论就是说在分布式存储系统中，最多只能实现上面的两点。 而由...
redis学习 -- 分布式数据库中的CAP原理
flyingfish
12-14 456
CAP是分布式系统的3个特性： C：Consistency（强一致性），写操作之后的读操作，必须返回该值。 A：Availability（可用性），用户发出请求，服务器一定要给出响应。 P：Partition tolerance（分区容错性），大多数分布式系统都分布在多个子网络，每个子网络就叫做一个区（partition），分区容错的意思是，区间通信可能失败。 一个分布式系统不可能同时很好地满足一致性、可用性和分区容错性这三个需求，最多只能同时较好地满足两个： CA：单点集群，满足一致性、可用性的
redis CAP
sainazuoan1的博客
03-15 88
主备：备份机不会参与业务。 主从复制：主机 从机 都可以访问 一个服务，两个客户端访问时 出现两种结果 ，即出现网络分区了，也就是出现脑裂了。 脑裂不一定不好，当需要注册服务时，有多个节点提出注册服务，只要一个能注册就行，不一定要全部ok。—即分区容忍性 过半：n/2+1 可以解决脑裂问题，少于辞职的团伙说话不管用 集群使用奇数台原因：3台集群 只允许挂一台，四台集群 只允许挂一台；但是四台的集群更容易挂。 后台运行关掉 日志打印到控制台 关闭AOF 人工模式实现故障切换： 主从模式： 从挂掉：运维修好后重
go语言 go-redis watch实例
最新发布
xiao_xiao_w的博客
04-25 318
讲一下对watch的理解在redis中watch是通过加了乐观锁的方法先获取事务执行前key值，如果在开始执行事务时检测到由于并发key被其他客户端修改了，就会终止事务如果用go-redis实现就是这样的其中watch即使对key值的监听，fn回调函数相当于如果key没有发生修改要执行的事务逻辑。
redis 持久化 数据安全性高
09-17
Redis是一种高性能的key-value存储系统，它通过内存中的数据...总之，Redis的持久化机制保证了数据的安全性，通过将数据持久化到磁盘上，即使在重启或崩溃的情况下也能够快速恢复数据，提高了系统的可靠性和稳定性。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Perley620

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值