09 Redis的集群：主从复制、CAP、PAXOS、cluster分片集群01

最新推荐文章于 2024-08-20 14:24:35 发布
最新推荐文章于 2024-08-20 14:24:35 发布
阅读量157 收藏 1
点赞数
分类专栏： 02 从网络到分布式 文章标签： linux 分布式 redis
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/jianmo777/article/details/118926783
版权

Redis的集群：主从复制、CAP、PAXOS、cluster分片集群01

理论部分：

redis单机有哪些问题？单点故障、容量有限、压力。

AKF

x、y、z轴分别解决单点故障、容量有限、压力问题。
x轴，一台单点故障，那就部署多台，做主备。主备是全量镜像，并不能解决压力问题。
y轴，按照业务功能，拆分为多台。
z轴，一个业务功能，按照优先级、逻辑再拆分。
在这里插入图片描述

一致性

通过AFK，单节点变多点，会引出数据一致性问题。

  • 强一致性
    同步方式，所有节点阻塞，直到数据全部一致。阻塞，代表服务不可用。使用强一致性，会破坏可用性。
    为什么一变多？是为了解决可用性。
    在这里插入图片描述

  • 弱一致性
    异步方式，容忍数据丢失一部分

在这里插入图片描述

  • 最终一致性
    同步访问一个可靠集群，响应速度足够快，只要从多节点取出数据最终一致即可
    在这里插入图片描述
    最终一致性，有可能客户端取到不一致数据，在没有处理完的时候会取到不一致数据，处理完后，最终是可以取到一致的数据的。

主备、主从

主备，客户端只能访问主机，不会访问备机。当主机挂掉后，由备机顶替主机提供服务。
主从，客户端可以访问主机，也可以访问从机。主从复制，主机提供增、删、改，同步数据给从机，从机提供查询服务。
主备、主从，主还是一个单点。主挂掉了，服务又不可用了，所以一般对主机做高可用。可以由人来手动做，但是人是最不可靠的，最好有一个监控程序来对主机进行实时监控，当主机挂掉，自动处理，实现自动的故障转移。
是程序，就可能出问题。所以，监控程序也要是一个集群。
在这里插入图片描述

监控集群

监控集群，如果有一些监控可用，另一些监控不可用，那么这个服务到底是可用还是不可用？

  • 势力范围
    如果3个监控节点，其中2台监控到可用，1台监控到不可用。那么势力范围分别是2、1。势力范围大的说的算，势力范围小的，说的不算。所以，势力范围2的说的算，服务可用。
  • 脑裂
    如果4个监控节点，其中3台建东到可用，1台监控到不可用，那么势力范围是3、1，势力范围大的3说的算；还是4个节点，如果其中2台监控到可用，2台监控到不可用，那么势力范围分别是2、2。势力范围一样大，脑裂了，区分不出来了。
  • 集群数量
    4个节点，可能出现2-2的势力范围，出现脑裂，解决方法，用3个节点；
    6个节点，可能出现3-3的势力范围，出现脑裂，解决方法，用5个节点。
    解决脑裂问题，集群数量：过半，n / 2 + 1，奇数台。

CAP原则

CAP原则又称CAP定理，指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。

  • 一致性（C）
    在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）
  • 可用性（A）
    保证每个请求不管成功或者失败都有响应。
  • 分区容忍性（P）
    系统中任意信息的丢失或失败不会影响系统的继续运作。

CAP原则的精髓就是要么AP，要么CP，要么AC，但是不存在CAP。

因此在进行分布式架构设计时，必须做出取舍。当前一般是通过分布式缓存中各节点的最终一致性来提高系统的性能，通过使用多节点之间的数据异步复制技术来实现集群化的数据一致性。

CAP理论就是说在分布式存储系统中，最多只能实现上面的两点。而由于网络硬件肯定会出现延迟丢包等问题，所以分区容错性是我们必须需要实现的。所以我们只能在一致性和可用性之间进行权衡，没有NoSQL系统能同时保证这三点。对于web2.0网站来说，关系数据库的很多主要特性却往往无用武之地。

实操部分：

主从复制

准备3个服务器3个客户端

准备3个配置文件，分别配置端口为6379、6380、6381。修改着3个配置文件，启动模式改成前台运行，关闭AOF和日志，然后启动3台redis-server。
在这里插入图片描述
修改配置文件

daemonize no
appendonly no
logfile ""

开3个窗口，分别启动3台服务器

redis-server ./6379.conf
redis-server ./6380.conf
redis-server ./6381.conf

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
再开3个窗口，作为3个客户端，分别连接服务器6379、6380、6381
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

使用命令指定主从

执行命令REPLICAOF，使6380从属于6379

REPLICAOF 127.0.0.1 6379	# 从属于6379

在这里插入图片描述
在这里插入图片描述
验证主从复制，在主机6389中添加一些数据，在从机了取数据
在这里插入图片描述

在这里插入图片描述
验证从机，不能写入数据
在这里插入图片描述
配置6381从属于6379，配置后原来6379中的数据就没有了，数据与主机6379一致
在这里插入图片描述

模拟主机挂了手动处理

ctrl+c，停掉6379，模拟主机挂了
在这里插入图片描述
从机6380、6381找不到主机了
在这里插入图片描述
在这里插入图片描述
现在我们把6380升级成主机

REPLICAOF no one # 首先把3780从属与6379取消掉

在这里插入图片描述
在这里插入图片描述
配置6381从属于6380

REPLICAOF 127.0.0.1 6380	# 从属于6380

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
测试处理后的主从
在这里插入图片描述
在这里插入图片描述

使用配置文件指定主从
replicaof <masterip> <masterport>	# 配置从属于谁
masterauth <master-password>	# 主机密码
replica-read-only yes			# 从机只读
replica-serve-stale-data yes	# 从机启动后从属于主机，主机在同步数据给从机的过程中，从机是否要对外提供历史数据的查询
repl-diskless-sync no	# yes使用网络，no使用磁盘IO
repl-backlog-size 1mb	# 增量复制，队列大小
min-replicas-to-write 3		# 
min-replicas-max-lag 10		#

在这里插入图片描述

哨兵Sentinel

准备配置文件
# 哨兵26379
port 26379
sentinel monitor mymaster 127.0.0.1 6379 2

# 哨兵26380
port 26380
sentinel monitor mymaster 127.0.0.1 6379 2

# 哨兵26381
port 26381
sentinel monitor mymaster 127.0.0.1 6379 2

在这里插入图片描述

启动redis服务器
# 启动6379
redis-server 6379.conf

# 启动6380，并从属于6379
redis-server 6380.conf --replicaof 127.0.0.1 6379

# 启动6381，并从属于6379
redis-server 6381.conf --replicaof 127.0.0.1 6379
启动哨兵
# 启动26379
redis-server 26379.conf --sentinel

# 启动26380
redis-server 26380.conf --sentinel

# 启动26381
redis-server 26381.conf --sentinel

在这里插入图片描述

自动故障转移

我们把redis主6379停掉，模拟主机出故障。查看6380、6381日志，与主机失去连接了。
在这里插入图片描述
在这里插入图片描述
查看哨兵日志，过一会，哨兵监控到6379挂了，开启新纪元，投票选举出6380作为新的主机，替换原来的主机6379，6381从属于6380，完成自动故障转移。
在这里插入图片描述

总结

哨兵只配置了主，怎么知道从的？
配置主从的时候，从机接入后，观察主机日志，会发现主机中可以打印出从机的信息。也就是说，主机是知道从机ip、端口号等信息的。
哨兵监控主机，就可以知道从机的信息。
哨兵是通过发布 / 订阅 发现其它哨兵的。
在这里插入图片描述

上一篇《08 Redis的持久化RDB、fork、copyonwrite、AOF、RDB&AOF混合使用》
下一篇《10 Redis的集群：主从复制、CAP、PAXOS、cluster分片集群02》

Garen Gosling
关注
专栏目录
redis集群
qq_38639813的博客
07-04 321
客户端调redis，主写成功，往从备份，从成功告诉主，然后主才给客户端返回告诉操作成功。这样如果从一旦挂了一个，就会不返回了，给人的感觉就是服务有问题了。所以强一致性容易造成集群不可用（不推荐使用） cap：一致性（强一致性）、可用性、分区容错性（集群）。不可兼得最多只能得两个。mysql是ca、redis集群是ap客户端调redis，主写成功立即返回。然后异步告诉从，至于从能否一定写成功不一定。弱一致性容易丢数据（redis主要使用的一种方式） 所以redis的分布式锁其实并不是特别准确，但是对于互联网企
java cap_【Java】分布式CAP原则
weixin_29603489的博客
02-12 3952
CAP原则介绍CAP原则又称CAP定理，指的是在一个分布式系统中，一致性(Consistency)、可用性(Availability)、分区容错性(Partition tolerance)。CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。CAP的三个指标一致性(Consistency)“all nodes see the same data at the same time”,...
（七）redis的集群：主从复制、CAP、PAXOS、cluster分片集群02
阿昊的博客
07-25 219
spring.io PROJECTS SPRING DATA 自学不用买书，看官方文档。 Spring dATA Redis learn reference Doc 所有Spring 对Rrdis做的事。 一，容量问题怎么解决？ X轴，HA，主从复制，没有解决容量问题 从客户端 1 业务拆分 2 hash+取模 弊端：取值的数必须固定 %3 %4 影响分布式下的扩展性 3 random 消息队列：一个往redis里扔lpush，一个从redis取rpop，消费的模式。 4 一致性哈希算法（更
Redis与CAP定理—理解数据存储的权衡
最新发布
hello.reader
08-20 1037
在分布式系统的设计中，理解CAP定理的重要性是不言而喻的。CAP定理指出，一个分布式系统不可能同时完全满足一致性（Consistency）、可用性（Availability）和分区容忍性（Partition Tolerance）。Redis作为一个广泛使用的键值存储系统，其在这三个方面的权衡尤其值得关注。本文将深入分析Redis如何应对这些挑战，并通过实际案例来说明这些权衡。Redis提供了多种配置选项，使得用户可以根据自己的具体需求在CAP三要素之间做出适当的权衡。
Redis概念(分布式集群、BASE、CAP)
轻描时光
04-12 170
Redis学习笔记（五）--分布式数据库CAP原理
长歌
01-15 954
传统数据库的ACID Atomicity 原子性 事务里面的所有操作要么全部做完，要么都不做，事务成功的条件是事务里的所有操作都成功，只要有一个操作失败，整个事务就失败，需要回滚。 Consistency 一致性 数据库要一直处于一致的状态，事务的运行不会改变数据库原本的一致性约束。 Isolation 独立性 并发的事务之间不会互相影响，如果一个事物要访问的数据
redis的集群：主从复制、CAP、sentinel哨兵、PAXOS、cluster分片集群02
dandanforgetlove的专栏
05-22 361
通过消息队列 topic&partition 来拆分redis Redis 集群教程 Redis Cluster Redis 集群没有使用一致性hash, 而是引入了哈希槽的概念. Redis 集群有16384个哈希槽,每个key通过CRC16校验后对16384取模来决定放置哪个槽.集群的每个节点负责一部分hash槽,举个例子,比如当前集群有3个节点,那么: 节点 A 包含 0 到 5500号哈希槽. 节点 B 包含5501 到 11000 号哈希槽. 节点 C 包含...
BAT架构师总结的Redis集群原理，图文并茂，超详细，小白也能轻松看懂
fangyi2011的博客
10-21 249
Redis作为一款性能优异的内存数据库，支撑着众多亿级流量平台，也成为很多互联网公司的标配。这里将以Redis Cluster集群为核心，基于最新的Redis5版本，从原理再到实战，玩转Redis集群 常见Redis集群方案 在介绍Redis Cluster集群方案之前，为了方便对比，先简单了解一下业界常见的Redis集群方案： 1 基于客户端分片 Redis Sharding是Red...
聊一聊Redis的Sentinel与Cluster
OrangeRawNorthland的博客
05-29 1504
文章目录哨兵模式什么是哨兵模式？哨兵模式的小细节哨兵是如何去监控这些节点的哨兵模式的下线模式哨兵模式的选举消息丢失Cluster模式什么是cluster模式？cluster模式的缺点cluster的启动流程Gossip协议Gossip协议的消息集群的伸缩Client是如何操作Cluster的Sentinel与Cluster的比较参考文献 哨兵模式 什么是哨兵模式？ 它是Redis的一种高可用架构，遵循CAP原则中的CP原则。我们在这里其实就可以把它看作为一个Zookeeper的集群，一般由3个以上的节点组成
常见面试题 ：分布式+微服务+MYSQL+Redis+JVM+Spring等等（0积分下载）
09-25
4. 高可用性：主从复制、读写分离、集群解决方案如Galera Cluster。 Redis是一款高性能的键值存储系统，常用于缓存和消息队列： 1. 数据类型：字符串、哈希、列表、集合、有序集合及其使用场景。 2. 持久化：RDB...
redis-7.redis的主从复制、CAP、PAXOS、cluster分片集群02
飘然渡沧海的博客
02-25 497
redis 关于spring-redis的API spring-api 要学会看官方文档，在github上看readme都挺重要的 解决单节点数据容量问题-sharding分片 可以根据业务拆分 按照算法+取模拆分，有弊端如果加机器去模不好计算 使用random随机分配节点，适合做消息队列 使用一致性哈希算法比较可靠，也可以叫映射算法 千万别整到mysql,redis数据没了可以重新加载，作为缓存时数据时非必要的 reids 链接对server端得成本很高，是对server端造成额
redis的集群：主从复制、CAP、PAXOS、cluster分片集群01
dandanforgetlove的专栏
05-22 561
单机、单点、单实例缺点： 1.单点故障 2.容量有限 3. 压力 强一致性 主从复制、读写分离会带来数据一致性问题 1.通过强一致性来解决，即主redis 进行阻塞，直到从redis写成功。 弱一致性 强一致性带来阻塞问题，可能会等待很久 1.通过异步方式解决强一致性问题，但是会丢失一部分数据 最终数据一致性 弱一致性会带来数据丢失问题 1.通过类似kafka 可靠集群来保证最终数据一致性 Redis使用默认的异步复制，其特点是低延迟和高性能 在使用 Redi...
（六）redis的集群：主从复制、CAP、PAXOS、cluster分片集群01
阿昊的博客
05-24 404
回顾：redis单机单线程 作为缓存，有RDB就够了，即使挂掉了恢复快，丢失了一小时的数据，也不过是穿透了，访问到了数据库。 作为数据库，为了不丢失数据，必须使用AOF。 单机的问题 1，单点故障 2，容量有限 3，压力 AKF 是微服务拆分的四个原则的第一项，实现的是一变多，但会引入新的问题：数据一致性。 X：全量，镜像 （主备 ），只能解决单点故障的问题 Y：单台有10G数据，但redis只有4G。按业务逻辑，功能拆分数据到多台redis上。 Z：基于一个优先级逻辑按编号拆分。 数据一致性：写的时候阻塞
Redis实战（七）：redis的集群：主从复制、CAP、PAXOS、cluster分片集群 2
热门推荐
寒泉
06-29 7万+
上节回顾 上一节我们讲了AKF拆分原则，讲了Redis主从复制的方式，是X轴方向的拓展，实现了HA，但是没有解决单节点数据的容量有限问题。 如何解决单节点数据容量的问题 如果数据可以分类，交集不多，可以考虑按业务拆分 如果数据没有办法划分拆解： 采用sharding分片 下面这三种方案都发生在客户端 1、Hash+取模（几乎没人用） 2、使用random随机分配节点，适合做消息队列 3、使用kmeta一致性哈希，规划一个环形哈希环 一致性哈希：https://www.jianshu.com/p/73
redis学习七redis的集群：主从复制、CAP、PAXOS、Cluster分片集群（二）
lsd&xql的博客
08-14 513
每个node都经过一个hash算法计算出一个环形hash所在的位置，然后data来了【包含了redis的key】，也是计算hash，找到环上的某个位置，这个环上除了通过node计算出来的点是物理的，其他的都是虚拟的点【就是data通过hash计算没落在物理点上的其他点】，再将物理点通过排序的方式放在一个treeMap上面，然后算出。此方式的弊端，模的数值是固定的，会影响分布式下的扩展，因为一个数在模3模4模10取得的结果是不一样的，可能扩展了以后就取不到数据了。通常可以使用topic来区分实际业务。....
CAP原则“大总结“及单机集群redis的所属
Unknownfuture的博客
08-05 1521
本来觉得CAP原则挺简单的，但一搜网上一大堆，翻译的版本不一，对概念的解析也各不相同。甚至有种越看越蒙的感觉… 因此分享下CAP原则的理解，主要指出了很多版本说法存在的问题。 当然，这是个人理解，如果有错。欢迎各位指出。 CAP原则 一致性Consistency : 访问所有节点，得到结果一致。（特别是更新操作完成后) 这里不采用"同一时刻"的说法，因为数据同步是需要时间的。关键是访问得到的数据一致 可用性Availability : 客户端访问集群中任意一个节点，系统能在有限的时间内给出非
redis学习六redis的集群：主从复制、CAP、PAXOS、Cluster分片集群（一）
lsd&xql的博客
08-12 458
replica-read-only yes从机是否是只读的状态repl-diskless-sync no (yes:master在内存中直接创建rdb，然后发送给slave，不会在自己本地落地磁盘了 no:则是通过磁盘IO先落到master的磁盘上面，然后再通过网络将rdb文件发送到slave)no的整个过程：1.从服务器向主服务器发送SYNC命令2.主服务器执行BGSAVE命令，生成RDB文件，并使用一个缓冲区记录从bgsave开始的所有写命令。...
redis集群如果保证数据一致性_从CAP理论到分布式一致性协议
weixin_36425412的博客
01-14 2231
前言在分布式开发中，我认为具备CAP理论与了解Raft、Zab等分布式一致性协议是十分有必要的，例如分布式锁的选择，你是选择Redis的主备集群（AP模型）还是选择ZK、etcd（CP模型）呢？关于分布式锁的文章 从分布式理论到如何做一个生产级别的分布式锁_|-| [- |_ |_ ()-CSDN博客_如何做一个分布式锁​blog.csdn.net如果不具备这些理论知识，我觉得是无法灵活选择且用好...
redis学习 -- 分布式数据库中的CAP原理
flyingfish
12-14 483
CAP是分布式系统的3个特性： C：Consistency（强一致性），写操作之后的读操作，必须返回该值。 A：Availability（可用性），用户发出请求，服务器一定要给出响应。 P：Partition tolerance（分区容错性），大多数分布式系统都分布在多个子网络，每个子网络就叫做一个区（partition），分区容错的意思是，区间通信可能失败。 一个分布式系统不可能同时很好地满足一致性、可用性和分区容错性这三个需求，最多只能同时较好地满足两个： CA：单点集群，满足一致性、可用性的
"深入了解Redis集群：主从、Sentinel和Cluster模式详解
为了提供更好的容错性和扩展性，Redis提供了三种集群模式：主从模式、Sentinel模式和Cluster模式。下面我们将对这三种集群模式进行详细介绍。 主从模式 主从模式是Redis集群中最简单的一种模式。在主从复制中，...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值