Redis进阶（2）——Redis数据的持久化 &amp； CAP分布式理论（高可用性

最新推荐文章于 2024-08-20 14:24:35 发布
最新推荐文章于 2024-08-20 14:24:35 发布
阅读量917 收藏 22
点赞数 15
分类专栏： 程序员 文章标签： 单元测试 功能测试 学习
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/2401_84140734/article/details/138641104
版权

img
img

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

运行容器

自定义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)上线

img
img

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

sentinel.conf
-d redis
redis-sentinel redis-sentinel.conf


### 测试哨兵


#### 关闭master服务器(redis\_6379)



> 
> 模拟主服务器宕机
> 
> 
> 


* 关闭主服务器(redis\_6379)之前
* 关闭主服务器(redis\_6379)
* 进入 容器（redis\_6380)检查状态


![在这里插入图片描述](https://i-blog.csdnimg.cn/blog_migrate/2199c263995455b332f5664603ae022d.png)


* 在新的master中添加数据
* 重新让之前的master(redis\_6379)上线




---


[外链图片转存中...(img-7ozsszXt-1715282776702)]
[外链图片转存中...(img-Dz1rQtHW-1715282776702)]

**网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。**

**[需要这份系统化的资料的朋友，可以戳这里获取](https://bbs.csdn.net/forums/4f45ff00ff254613a03fab5e56a57acb)**

**一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！**
2401_84140734
关注
专栏目录
【微服务 Spring Cloud 2】为什么90%的开发者放弃传统的技术架构，而选择微服务？
学Java，找哪吒
04-23 7848
一、可观测性发展 1、单体应⽤ - ⼿动⽇志排查 单个应用承载复杂逻辑，应用实例数量有限，本地Debug可以解决大部分问题。 2、分布式服务 - 基础指标+⽇志检索 业务逻辑模块化拆分，节点数量依然可控，简单节点指标检查和架构自带调用链可以满足诉求。日志检索问题初现。 3、容器化微服务 - Prometheus+ELK+Tracing 服务部署容器化，节点数量无法手动管理。K8s控制面+Prometheus成为标配，ELK协助日志汇聚，检索。Tracing诉求强烈，OpenTracing&amp;OpenT
高薪程序员&Java面试题精讲系列汇总
一一哥
09-24 2961
因为CSDN没有分类归纳博客的功能，所以特写本帖汇总《高薪程序员面试题精讲系列教程》，方便大家查阅！希望各位小伙伴，可以从我的拙作中能对Java的高频面试题有所掌握，也希望各位可以多给与指教！目前本系列文章持续更新中，敬请关注...... 如果你觉得本系列博文对你有帮助，请给个 点赞评论 吧，手写博文不易，一篇文章可能得花一两天的时间才能写好，你的支持是我坚持下去的动力！ 本系列面试题涵盖的内容如下所示： 面试题系列文章链接： 高薪程序员&amp;面试题精讲系列01之开篇介绍 高薪程序员&a.
redis的三种模式以及涉及到的CAP理论
weixin_56503821的博客
08-10 4620
Redis的三种模式 一、cluster的架构变化 1、单机redis：redis单机模式，保证了数据的一致性而牺牲了可用性，即不能够实现高可用，只是保证了用户可以看到相同的数据和当网络通信出问题是能够保证隔离的子系统能够继续运行，因为在单机模式中master与slave之间不存在通信问题 所以当master节点挂掉以后子节点不能保证能够正常的提供服务 2、哨兵redis：哨兵在单机redis上做了些许改动增加一个sentinel也就是哨兵来实现redis的可用性，让单机的redis的master和slav
Redis与CAP定理—理解数据存储的权衡
最新发布
hello.reader
08-20 1083
在分布式系统的设计中，理解CAP定理的重要性是不言而喻的。CAP定理指出，一个分布式系统不可能同时完全满足一致性（Consistency）、可用性（Availability）和分区容忍性（Partition Tolerance）。Redis作为一个广泛使用的键值存储系统，其在这三个方面的权衡尤其值得关注。本文将深入分析Redis如何应对这些挑战，并通过实际案例来说明这些权衡。Redis提供了多种配置选项，使得用户可以根据自己的具体需求在CAP三要素之间做出适当的权衡。
Redis -- 分布式数据库CAP原理
Syntactic Sugar
11-06 292
文章目录传统的ACID分别是什么CAPBASE分布式+集群简介 传统的ACID分别是什么         ●A (Atomicity) 原子性         ●C (Consistency) 一致性         ● I (Isolation) 独立性  &
Redis主从复制、CAP原则
qq_45376284的博客
06-27 93
Redis主从复制、CAP原则
【Redis】简介
a6458360的博客
08-24 784
目录 # Redis简介 [# 安装](https://blog.csdn.net/weixin_39407066/article/details/107447707?ops_request_misc=%7B%22request%5Fid%22%3A%22159822486119195188312616%22%2C%22scm%22%3A%2220140713.130102334…%22%7D&amp;request_id=159822486119195188312616&amp;biz_id=0&amp;
大数据技术与实践
CSDN_Tianxw的博客
12-11 563
11.1 大数据概述 11.1.1 大数据产生的背景 大数据（big data），IT行业术语，是指无法在一定时间范围内用常规软件工具进行捕捉、管理和处理的数据集合，是需要新处理模式才能具有更强的决策力、洞察发现力和流程优化能力的海量、高增长率和多样化的信息资产。   在维克托·迈尔-舍恩伯格及肯尼斯·库克耶编写的《大数据时代》 中大数据指不用随机分析法（抽样调查）这样捷径，而采用所有数据进行分析...
CAP理论（Redis）
weixin_34117522的博客
03-27 783
2019独角兽企业重金招聘Python工程师标准>>> ...
Redis__分布式数据库CAP原理
兴趣是最好的老师
04-14 229
CAP理论就是说在分布式存储系统中，最多只能实现上面的两点。 而由于当前的网络硬件肯定会出现延迟丢包等问题，所以分区容忍性是我们必须需要实现的。 所以我们只能在一致性和可用性之间进行权衡，没有NoSQL系统能同时保证这三点。 C:强一致性 A：高可用性 P：分布式容忍性 CA 传统Oracle数据库 AP 大多数网站架构的选择 CP Redis、Mongodb 注意：分布式架构的时候必须做出取舍。 一致性和可用性之间取一个平衡。多余大多数web应用，其实并不需要强一致性。...
【Redis】第4讲 分布式数据库CAP原理
a272329874a的博客
09-22 145
分区是常态，不可避免，三者不可共存可用性和一致性是对立的一致性高，可用性低一致性低，可用性高因此，根据CAP原理将NoSQL数据库分成了满足CA原则，满足CP原则和满足AP原则三大类。CA：单点集群，满足一致性，可用性的系统，通常在可扩展性上不太强大。CP：满足一致性，分区容忍性的系统，通常性能不是特别高。AP：满足可用性，分区容忍性的系统，通常可能对一致性要求低一些。
Redis 学习01 : CAP理论 和衍生出来的BASE理论
wdw18668109050的博客
09-12 784
CAP原则又称CAP定理，指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性）。 三者不可兼得，只能满足3进2。 ● 一致性Consistency（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）。就是要求数据实时的精准。 ● 可用性Avai...
redis CAP
sainazuoan1的博客
03-15 115
主备：备份机不会参与业务。 主从复制：主机 从机 都可以访问 一个服务，两个客户端访问时 出现两种结果 ，即出现网络分区了，也就是出现脑裂了。 脑裂不一定不好，当需要注册服务时，有多个节点提出注册服务，只要一个能注册就行，不一定要全部ok。—即分区容忍性 过半：n/2+1 可以解决脑裂问题，少于辞职的团伙说话不管用 集群使用奇数台原因：3台集群 只允许挂一台，四台集群 只允许挂一台；但是四台的集群更容易挂。 后台运行关掉 日志打印到控制台 关闭AOF 人工模式实现故障切换： 主从模式： 从挂掉：运维修好后重
Redis - CAP原则 =＞ 缓存与数据库的一致性
key_768的博客
08-07 1940
这里的数据库是指Mysql等存放在磁盘的数据库，缓存是指Redis等在内存的数据库 实时同步 实时同步：缓存或DB修改，另一方同步修改 强一致性要求比较高，可采用实时同步：查询时先查询缓存，查询不到再查询数据库，并保持到缓存；更新缓存时先更新数据库，再将缓存设置为过期，更新数据（建议不要更新缓存内容，而是设置缓存过期） 非实时同步 非实时同步：缓存或数据库修改，另一方不需要同步修改 非实时同步： 定时任务：设置一定时间间隔更新数据 异步队列： 并发程度高，可以采用异步队列，可此案有kafka等消息中.
【Redis】CAP问题 C（一致性）、A（可用性）、P（网络分区容错性）；Cache aside pattern旁路缓存模式：Redis缓存保证AP的策略：就是旁路缓存模式+延时双删（一般最多2秒）
落霞与孤鹜齐飞，秋水共长天一色。
10-06 776
当网络故障的时候，分区容错性P指的是：系统仍然可用，但不一定保证数据一致性了。
Redis分布式数据库原理CAP(理论篇)
ctlgq的博客
10-05 1329
关系型数据库遵循ACID规则 事务在英文中是transaction，和现实世界中的交易很类似，它有如下四个特性： 1、A (Atomicity) 原子性 原子性很容易理解，也就是说事务里的所有操作要么全部做完，要么都不做，事务成功的条件是事务里的所有操作都成功，只要有一个操作失败，整个事务就失败，需要回滚。比如银行转账，从A账户转100元至B账户，分为两个步骤：1）从A账户取100元；2）存入10...
Redis高级特性详解：持久化、主从复制与哨兵
"Redis是一个高性能的键值对数据库，提供了持久化、主从复制和哨兵机制等高级特性，以确保数据的安全性、高可用性和读取性能。本文详细介绍了这三个核心概念。" Redis持久化是确保数据在Redis实例重启后仍然保留的...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值