微信音乐做mp3下载网站,制作网站首页,网站建设河北石家庄,网站建设黄页免费观看概述 参考#xff1a;What are Redis Cluster and How to setup Redis Cluster locally ? | by Rajat Pachauri | Medium Redis Cluster 的工作原理是将数据分布在多个节点上#xff0c;同时确保高可用性和容错能力。以下是 Redis Cluster 运行方式的简要概述#xff1a;
…概述 参考What are Redis Cluster and How to setup Redis Cluster locally ? | by Rajat Pachauri | Medium Redis Cluster 的工作原理是将数据分布在多个节点上同时确保高可用性和容错能力。以下是 Redis Cluster 运行方式的简要概述
节点发现Redis 集群使用一种称为“gossip 协议”的概念进行节点发现。每个节点都会维护集群中其他节点的列表并定期与一些随机选择的节点共享有关集群状态的信息。这有助于节点发现和加入集群。数据分片Redis Cluster 使用一致性哈希将数据划分为多个哈希槽。集群支持 16384 个哈希槽每个键使用哈希函数映射到特定槽。哈希槽分布在集群中的节点上。主-副本复制Redis 集群遵循主-副本复制模型。每个哈希槽都与特定的主节点相关联并且该槽中的数据被复制到一个或多个副本节点。副本提供冗余并在主节点发生故障时充当故障转移节点。客户端交互客户端可以连接到 Redis 集群中的任何节点。当客户端发送与特定键相关的命令时集群会使用该键的哈希槽来确定负责该槽的节点。然后使用 MOVED 或 ASK 重定向响应将客户端透明地重定向到适当的节点。故障转移和高可用性Redis 集群支持自动故障转移。当主节点发生故障时其副本之一将自动升级为主节点从而确保数据的持续可用性。集群使用共识协议来选举新的主节点。客户端通过重定向响应更新新的主节点信息。集群配置Redis 集群维护一个集群配置其中包含有关节点、哈希槽和副本的信息。当节点加入或离开集群时此配置会动态更新。集群节点交换消息以就集群配置达成共识并确保其一致性。
通过在多个节点之间分配数据和负载Redis Cluster 可实现水平扩展并提高性能。它提供容错能力因为副本可以接管发生故障的主节点的角色。集群还平衡哈希槽的分布并确保每个节点负责一部分槽从而使集群能够高效扩展。
Redis cluster 简介
Redis cluster 是一种去中心化的 Redis 分布式集群解决方案。通过数据自动分片分配到多个主节点之间每个主节点 都是 主从搭配、自动故障检测实现了高可用和高性能。 特点
Redis Cluster 具有以下几个特点 可扩展性横向扩展通过向集群添加更多节点可以增加 Redis 系统的整体容量和吞吐量。 扩展可以分为Las垂直扩展scale up、水平扩展scale out 垂直拓展升级单个 Redis 的硬件配置比如增加内存容量、磁盘容量、使用更强大的 CPU。【部署简单但是当数据量大并且使用 RDB 实现持久化会造成阻塞导致响应慢。另外受限于硬件和成本拓展内存的成本太大比如拓展到 1T 内存】水平拓展横向增加 Redis 实例个数每个节点负责一部分数据。【便于拓展同时不需要担心单个实例的硬件和成本的限制。但是切片集群会涉及多个实例的分布式管理问题需要解决如何将数据合理分布到不同实例同时还要让客户端能正确访问到实例上的数据】 高可用性主从复制和故障转移机制提高了集群的可靠性。 主从复制模式从节点实时同步主节点的数据。这种结构不仅提高了数据的冗余性还在主节点出现故障时提供了数据的可用性。故障转移机制当主节点不可用时从节点可以自动提升为主节点。这种自动化的故障处理机制减少了人为干预的需求确保了系统的持续可用性。
使用场景
高并发应用需要处理大量并发请求的场景如电商、社交平台。
数据分片需求需要水平扩展存储容量的场景。
高可用性需求需要提供数据冗余和自动故障恢复的应用。
优缺点
优点
水平扩展通过添加节点轻松扩展集群容量。高可用性主从复制和故障转移机制提高了集群的可靠性。数据分布均衡哈希槽机制确保数据在集群中均匀分布。
缺点
复杂性增加集群的配置和管理相较于单节点模式更加复杂。数据一致性问题可能出现部分数据不可用的情况需要应用层处理。资源消耗维护多个节点的状态需要额外的资源和网络通信。
Redis Cluster 实现原理
数据分片与哈希槽
Redis 的数据分片sharding是将 Redis数据集 分割为多个部分分别存储在不同的 Redis节点上的技术。通过数据分片技术可以将 一个单独的 Redis数据库扩展到多个物理机器上从而提高 Redis集群的性能、扩展性。 当 16384 个槽都分配完全Redis 集群才能正常工作。 在Redis的Cluster集群模式中使用**哈希槽(hash slot)**的方式来进行数据分片将整个数据集划分为多个槽每个槽分配给一个节点这里的节点是由 主、从模式构成的。
客户端如何访问/插入数据的
客户端访问数据时先计算出数据对应的槽然后直接连接到该槽所在的节点进行操作。具体的
如何分片的Redis集群模式中使用哈希槽hash slot的方式将数据分片。
首先将数据集划分为多个槽每个槽分配给一个节点。一个节点会对应多个槽客户端访问数据时先计算出数据对应的槽然后连接到该槽所属的 Redis节点上然后在该节点上访问对应数据。 具体流程为假设要查询 键为key1的数据
对key1进行哈希计算使用CRC16算法计算的结果就是 key1的哈希值假设得到哈希值为12345。对哈希值取模16384结果为12345。key1映射到哈希槽12345由节点B负责。
数据分片的作用
Redis Cluster中的数据分片具有以下特点
提升性能和吞吐量通过在多个节点上分散数据可以并行处理更多的操作从而提升整体的性能 和吞吐量。这在高流量场景下尤其重要因为单个节点可能无法处理所有请求。提高可扩展性分片使得Redis可以水平扩展。可以通过添加更多节点扩展数据库的容量和处理能 力。降低单个节点的内存和计算需求每个节点只处理数据的一部分这降低了单个节点的内存和计算需求。避免单点故障在没有分片的情况下如果唯一的Redis服务器发生故障整个服务可能会停止。 在分片的环境中即使一个节点出现问题其他节点仍然可以继续运行。数据冗余和高可用性在某些分片策略中如Redis集群每个分片的数据都可以在集群内的其他 节点上进行复制。这意味着即使一个节点失败数据也不会丢失从而提高了系统的可用性。
节点类型主节点、从节点
在 Redis Cluster 中节点分为两种类型主节点Master和从节点Slave。 上面数据分片时所说的 会将数据分片到不同的节点上。这里的节点就是由 一个 master 和 1或多个slave 组成的。 主节点是数据的主要存储位置负责处理与数据相关的所有操作如读、写请求数据分片等。从节点主要任务是复制主节点的数据。每个主节点可以有一个或多个从节点从节点实时同步主节点的数据。这种设计保证了数据的冗余性和高可用性。
注意关于Redis Cluster 中从节点是否可以支持 读服务 默认情况下从节点不负责处理读服务所有的写请求和读请求都会被路由到主节点。 然而Redis提供了READONLY命令允许客户端将读请求路由到从节点。 但是这种做法需要谨慎因为它可能会引入一些问题比如 延迟读取从节点可能不会立即反映出主节点的最新数据变化因为数据复制是异步进行的。一致性风险如果主从节点之间的网络延迟较大从节点可能会提供过时的数据
Redis Cluster 的通信协议Gossip 协议 Redis 的集群节点之间的通信采取 gossip 协议进行通信在 redis cluster 架构下每个 redis 要放开两个端口号比如一个是 6379另外一个就是 加10000 的端口号比如 1637916379 端口号是用来进行节点间通信的。 Gossip protocol 也叫 Epidemic Protocol 流行病协议实际上它还有很多别名比如“流言算法”、“疫情传播算法”等。
Gossip protocol 流言协议是利用一种 随机、带有传染性的方式将信息传播到整个网络中并在一定时间内使得系统内所有节点数据一致。
Gossip协议的执行过程简答描述为Gossip 过程是由种子节点发起当一个种子节点有状态需要更新到网络中的其他节点时它会随机的选择周围几个节点散播消息收到消息的节点也会重复该过程直至最终网络中所有的节点都收到了消息。这个过程可能需要一定的时间由于不能保证某个时刻所有节点都收到消息但是理论上最终所有节点都会收到消息因此它是一个最终一致性协议。 Gossip协议优缺点
优点
扩展性 网络可以允许节点的任意增加和减少新增加的节点的状态最终会与其他节点一致。容错 网络中任何节点的宕机和重启都不会影响 Gossip 消息的传播Gossip 协议具有天然的分布式系统容错特性。去中心化 Gossip 协议不要求任何中心节点所有节点都可以是对等的任何一个节点无需知道整个网络状况只要网络是连通的任意一个节点就可以把消息散播到全网。一致性收敛 Gossip 协议中的消息会以一传十、十传百一样的指数级速度在网络中快速传播因此系统状态的不一致可以在很快的时间内收敛到一致。消息传播速度达到了 logN。简单 Gossip 协议的过程极其简单实现起来几乎没有太多复杂性。
缺点
消息的延迟 由于 Gossip 协议中节点只会随机向少数几个节点发送消息消息最终是通过多个轮次的散播而到达全网的因此使用 Gossip 协议会造成不可避免的消息延迟。不适合用在对实时性要求较高的场景下。消息冗余 Gossip 协议规定节点会定期随机选择周围节点发送消息而收到消息的节点也会重复该步骤因此就不可避免的存在消息重复发送给同一节点的情况造成了消息的冗余同时也增加了收到消息的节点的处理压力。而且由于是定期发送因此即使收到了消息的节点还会反复收到重复消息加重了消息的冗余。
Redis Cluster的Gossip机制
Redis Cluster 是在 3.0 版本引入集群功能。为了让让集群中的每个实例都知道其他所有实例的状态信息Redis 集群规定各个实例之间按照 Gossip 协议来通信传递信息。 上图展示了主从架构的 Redis Cluster 示意图其中
实线表示节点间的主从复制关系虚线表示各个节点之间的 Gossip 通信。
Redis Cluster 中的每个节点都维护一份自己视角下的当前整个集群的状态信息元数据信息主要包括
当前集群状态集群中各节点所负责的 slots信息及其migrate状态集群中各节点的master-slave状态集群中各节点的存活状态及怀疑Fail状态
Redis Cluster 的节点之间发送消息的类型
知道了 节点之间是通过 Gossip 协议进行消息的发送现在来看看它们之间发送消息的类型。较为重要的如下所示
消息说明meet通过「cluster meet ip port」命令已有集群的节点会向新的节点发送邀请加入现有集群然后新节点就会开始与其他节点进行通信ping节点按照配置的时间间隔向集群中其他节点发送 ping 消息消息中带有自己的状态还有自己维护的集群元数据和部分其他节点的元数据pong返回ping和meet包含自己的状态和其他信息也可以用于信息广播和更新fail某个节点判断另一个节点fail之后就发送fail给其他节点通知其他节点指定的节点宕机了
定时ping/pong消息心跳机制
Redis Cluster 中的节点都会定时地向其他节点发送 PING 消息来交换各个节点状态信息检查各个节点状态包括在线状态、疑似下线状态 PFAIL 和已下线状态 FAIL。
Redis 集群的定时 PING/PONG 的工作原理可以概括成两点 一是每个实例之间会按照一定的频率从集群中随机挑选一些实例把 PING 消息发送给挑选出来的实例用来检测这些实例是否在线并交换彼此的状态信息。 例自身的状态信息、部分其它实例的状态信息以及 Slot 映射表。 二是一个实例在接收到 PING 消息后会给发送 PING 消息的实例发送一个 PONG 消息。PONG 消息包含的内容和 PING 消息一样。 故障检测与自动故障转移
Redis Cluster保证高可用High Availability主要还是依靠故障检测与故障转移。
自动故障检测
故障检测的机制如下通过Gossip协议发送消息进行检测 关于节点参与情况说明 主观下线每个节点包括主节点和从节点都会检测其他节点的状态。如果检测到某个节点不可用会将其标记为主观下线PFAIL。客观下线主节点之间会交换彼此的主观下线状态如果超过半数的主节点都认为某个节点不可用则该节点会被标记为客观下线FAIL。 疑似下线Redis Cluster 中的节点会定期检查已经发送 PING 消息即上述的心跳机制的接收方节点是否在规定时间 ( cluster-node-timeout ) 内返回了 PONG 消息如果没有则会将其标记为疑似下线状态possible failPFAIL。 客观下线当一个节点将另一个节点标记为疑似失败后它会通过Gossip协议将这个信息传播给其他节点。如果一个节点从大多数主节点那里都收到了某个节点的疑似失败信息那么这个节点将被标记为客观失败FAIL。并将该节点 客观下线的信息发送给所有节点。
这时集群会触发故障转移流程从失败节点的从节点中选举一个新的主节点。
自动故障转移 节点参与情况说明 从节点投票当一个主节点被标记为客观下线后它的从节点会发起故障转移过程。故障转移请求会被发送到其他主节点以请求授权进行故障转移。 授权投票其他主节点会对故障转移请求进行投票同意票数超过半数后候选从节点会被提升为新的主节点。 当Redis Cluster中的主节点被标记为客观下线FAIL时会触发故障转移failover流程。故障转移failover是指当主节点不可用时从节点自动提升为新的主节点以保证集群的高可用性。故障转移的流程包括以下几个步骤
投票选举被标记为客观下线的主节点的从节点会尝试提升为主节点。 这些从节点会向集群中的其他主节点请求支持开始选举过程。各个主节点会根据从节点的优先级配置文件中的 slave-priority 参数、复制偏移量replication offset等因素进行投票。 选择新的主节点 得到多数票超过半数的从节点会被提升为新的主节点。如果没有从节点得到足够的票数则选举失败并在短时间后重试。 配置更新当选举出新的主节点后该主节点会通知所有的其他节点告知他是新的主节点。数据同步原主节点的从节点现在会成为新主节点的从节点并开始从新主节点同步数据。如果原主节点恢复后重新加入集群它也会成为新主节点的从节点并从新主节点同步数据。
重定向
为什么需要重定向
当客户端第一次连接到 Redis Cluster 时它会连接到集群中的一个节点通常是配置好的一个或多个节点之一。这个节点会提供当前集群的拓扑结构包括每个节点负责的哈希槽范围。
但是后续如果节点进行扩容、缩容之后每个节点的哈希槽范围会改变。此时客户端是无法感知的。
之后通过重定向一次之后客户端会根据节点返回 MOVED 或 ASK 错误客户端更新其拓扑结构并将请求重发到新的节点。
在此之后客户端维护的拓扑结构更新到最新的状态。
一句话在 Redis Cluster 中每个键通过哈希槽分配到不同的节点。如果你向某个节点写入数据但该数据应该存储在另一个节点上Redis Cluster 会返回重定向指令告诉你应该访问哪个节点。这确保了数据的分布和存取的正确性。
重定向指令类型
MOVED当客户端请求的键在另一个节点上时节点会返回MOVED指令。该指令包含目标节点的地址。客户端收到MOVED指令后会重新请求目标节点。
ASK在数据迁移过程中如果某个键正在从一个节点迁移到另一个节点当客户端请求这个键时节点会返回ASK指令。ASK指令告诉客户端临时访问新的目标节点通常在数据迁移完成之前。
MOVED指令
重定向过程的详细步骤
初始请求客户端向节点A发送请求如果键不在节点A的哈希槽范围内。返回MOVED指令节点A返回一个MOVED指令包含目标节点B的地址。客户端重试客户端向节点B重新发送请求。返回结果节点B处理请求并返回结果。
注意重定向MOVED类型客户端还会更新本地缓存将该 slot 与 Redis 实例对应关系更新正确。 ASK指令 迁移过程中的请求如果某个键正在从节点A迁移到节点B客户端请求这个键时节点A会返回一个ASK指令。 临时访问客户端向节点B发送请求并在请求前发送ASKING指令表明这是一次临时访问。 数据迁移完成后客户端可以正常访问节点B不再需要发送ASKING指令。
注意ASK 指令并不会更新客户端缓存的哈希槽分配信息。 扩容、缩容
缩容原理
缩容流程
选择要移除的节点哈希槽重分配在缩容过程中首先需要将要移除节点上的哈希槽迁移到其他节点。这样可以确保数据的完整性和一致性。数据迁移哈希槽的迁移意味着对应数据的迁移Redis Cluster会自动将数据从一个节点复制到另一个节点。将节点从集群中移除更新集群状态集群状态会随时更新以反映哈希槽和数据的迁移情况。移除节点一旦所有数据和哈希槽迁移完成就可以安全地将节点从集群中移除。
扩容原理
扩容流程
启动新节点将新节点加入集群重新分配哈希槽在扩容过程中需要将部分哈希槽从现有节点迁移到新节点以确保数据分布均匀。哈希槽的重新分配可以通过手动指定或者使用 reshard 命令自动进行。数据迁移哈希槽迁移意味着对应数据的迁移Redis Cluster会自动将数据从一个节点复制到另一个节点。数据迁移过程中Redis Cluster会确保数据的一致性和完整性。更新集群状态集群状态会随时更新以反映哈希槽和数据的迁移情况。新节点加入集群后集群中的其他节点会通过Gossip协议感知新节点的存在并更新自己的拓扑信息。验证集群状态
主、从节点如何建立的通信
步骤如下
初始配置每个节点启动时都会加载其配置文件其中包含节点的 ID、集群状态和分配的哈希槽信息。如果是从节点还会配置它所跟随的主节点信息。启动节点、发现节点、加入集群节点通过 Gossip 协议发现和加入集群。每个节点会周期性地向其他节点发送 PING 消息接收 PONG 响应了解对方的存在和状态。主从节点建立关系 从节点启动时根据配置文件中的信息向其指定的主节点发送复制请求PSYNC。主节点接收请求后开始向从节点复制数据。复制完成后从节点进入同步状态定期向主节点发送 ACK 消息确认接收到的数据。
复制请求PSYNC
这里的复制请求PSYNC主要使用的是 Redis 协议REdis Serialization Protocol, RESP。 RESPRedis Serialization Protocol 是 Redis 的内部协议用于客户端和服务器之间的通信也用于 Redis 集群节点之间的通信。该协议简单、高效且便于实现。 复制请求PSYNC的流程 读取 replicaof 指令获取主节点信息 从节点的配置文件中会包含一条 replicaof 指令用于指定它要跟随的主节点的 IP 地址和端口。例如 port 7001
cluster-enabled yes
cluster-config-file nodes-7001.conf
cluster-node-timeout 5000
appendonly yes
replicaof 127.0.0.1 7000启动从节点当从节点启动时它会读取配置文件并解析 replicaof 指令。 连接主节点从节点根据 replicaof 指令中指定的 IP 地址和端口尝试连接主节点。 发送 PSYNC 命令一旦连接成功从节点会向主节点发送 PSYNC 命令以请求复制。PSYNC 命令用于部分重同步或全量重同步。 PSYNC replicationid offset主节点响 主节点接收到 PSYNC 命令后就可以开始数据复制同步了。
参考
Redis 高可用篇Cluster 集群原理剖析集群可以无限拓展么_redis cluster_码哥字节_InfoQ写作社区What are Redis Cluster and How to setup Redis Cluster locally ? | by Rajat Pachauri | MediumRedis Cluster集群节点间通信Gossip协议 | 浮生无事Blog (fushengwushi.com)认识Redis集群——Redis Cluster - JJian - 博客园 (cnblogs.com)Redis 高可用篇Cluster 集群原理剖析集群可以无限拓展么_redis cluster_码哥字节_InfoQ写作社区
