Redis——Raft算法

最新推荐文章于 2025-09-04 21:02:08 发布
最新推荐文章于 2025-09-04 21:02:08 发布
阅读量1.7k 收藏 8
点赞数 5
CC 4.0 BY-SA版权
分类专栏： redis 文章标签： redis 数据库 缓存
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/m0_72165281/article/details/143985604

Raft使用较为广泛的强一致性、去中心化、高可用的分布式协议，即使在网络、节点故障等情况下，多个节点依然能达到一致性。
其中redis、etcd等都用到了这种算法

在Redis集群中，采取的主从复制结构，当主节点宕机后，哨兵会将其中的一个从节点升级为主节点，而其中选举的过程就是Raft算法。

原理：

  • leader：领导者，其负责和客户端通信，接收来自客户端的命令并将其转发给follower
  • follower：跟随者，其一丝不苟的执行来自leader的命令
  • candidate：候选者，当follower长时间没收到 leader的消息就会向成为候选者，抢夺成为leader的资格。

下面我讲一下以一个例子来讲解一下整个的过程：

假设我们有三个哨兵（sentenal1，sentenal2，sentenal3），一个主节点（redis-master），两个从节点（redis-slave1,redis-slave2）

当主节点出现故障,就会触发重新⼀系列过程.在这里插入图片描述

主观下线：当主节点宕机后，此时主节点和3个哨兵之间的心跳没有了。
这是哨兵认为，主节点出现了严重事故，因此三个哨兵均会把主节点判定为主观下线
客观下线：哨兵sentenal1，sentenal2，sentenal3均会对主节点故障进行投票，当故障票数 > 陪定的法定票数的时候，就将它认为是客观下线

假设一共有3个哨兵节点，S1,S2,S3

  • 每个哨兵节点都会给其他哨兵节点发起一个投票请求，
  • 此时收到请求的节点会选择是否投还是不投（每个哨兵节点都只有一票）
  • 一轮投票结束后，发现得票数数超过节点的一半的时候，自动升级为leader
  • leader会负责挑选一个从节点升级为新的主节点，当其他的sentenal发现新的主节点出现的时候，就说明选举结束了

那么挑选的规则是什么呢？

  • 比较优先级：优先级高的上位，优先级是slave-priority或者replica-priority
  • 比较replication offset，这个反映了从节点有多少数据和主节点一样，replication offset高的上位
  • 比较run id，谁的id小，谁上位

哨兵节点不能只有一个吗？

当然不能，我们要知道在redis一般是以集群的方式来部署的，那么就有可能哨兵节点挂了，那么就会影响系统的可用性（这是不能忽视的）

哨兵节点设置为奇数还是偶数

哨兵节点设置为奇数，方便选举leader，得票数容易超过总节点的一半

投票时，如果超过了超时时间导致选取不出leader怎么办？

raft算法其实都有考量，所有节点都会被分配不同的超时时间，因为如果都分配相同的超时时间，导致所有节点同时过期，导致无法选举出leader的情况

如果哨兵节点是偶数，出现了平票怎么办

此时，所有节点都会变为follower状态，重新设置随机的超时时间，重新进行选举

Redis——Redis Cluster集群原理
庄小焱
03-14 5172
摘要 我们平时习惯于使用 Rabbitmq 和 Kafka 作为消息队列中间件，来给应用程序之间增加异步消息传递功能。这两个中间件都是专业的消息队列中间件，特性之多超出了大多数人的理解能力。使用过 Rabbitmq 的同学知道它使用起来有多复杂，发消息之前要创建 Exchange，再创建 Queue，还要将 Queue 和 Exchange 通过某种规则绑定起来，发消息的时候要指定 routingkey，还要控制头部信息。消费者在消费消息之前也要进行上面一系列的繁琐过程。但是绝大多数情况下，虽然我们的消息
Redis——Redis扩展应用与实战
庄小焱
04-20 702
摘要 主要是介绍了的redis的哨兵机制以及底层原理。 哨兵模式(raft)与Zookeeper模式（zab）选主的总结 Redis中的Sentinel选主相对来说更简单，因为不涉及事务状态的一致性 Sentinel选主是基于raft协议，Zookeeper则基于Zab协议 二者都是收到半数的选票就选举成功，同样的都是分布式部署 Sentinel投票发消息主要内容是Sentinel id和配置纪元，Zookeeper则是 zxid和 sid Sentin...
redisraft:一个 Redis 模块，可以从多个 Redis 实例创建一致的 Raft 集群
07-24
RedisRaft :warning: RedisRaft 仍在开发中，尚未准备好用于任何实际生产用途。 目前请不要将其用于任何关键任务目的。 强一致性 Redis 部署 RedisRaft 是一个 Redis 模块，它实现了，可以创建强一致性的 Redis 服务器集群。 Raft 算法由 Willem-Hendrik Thiart 的提供。 主要特点 强一致性（在语言中，该系统优先考虑一致性和分区容忍性）。 支持大多数 Redis 数据类型和命令 动态集群配置（添加/删除节点） 日志压缩的快照 可配置的仲裁或快速读取 入门 建造 该模块大多是自包含的； 它的几个依赖项可作为deps下的 git 子模块使用。 要编译模块，您将需要： 构建必需品（编译器、GNU make 等） 制作 GNU 自动工具（autoconf、automake、libtool） libbsd-dev（在 Deb
一文吃透 Redis：主从复制 / 哨兵 / 集群模式 + 缓存 + 分布式锁
2401_82677021的博客
07-24 1381
主从复制解决的问题：单点问题单点问题：单个redis节点，可用性不高，性能有限。主从复制的特点：1，主节点可以用来读写，从节点只能用来读，可以减少主节点的访问压力。2，主从复制存在多种拓扑结构：可以在适当的场景使用适当的拓扑结构，比如一主多从的结构，同步操作快，但是消耗的网络资源多，因为主节点要通过网络和所有从节点实现同步。而树形结构，主节点消耗的网络资源减少了，但是如果树的层级太高，会造成数据同步的延迟增长加。3，复制分为全量复制，部分复制和实时复制。
[redis 源码走读] - redis 与 raft 算法
smart_an的专栏
06-01 951
作者简介：大家好，我是哥，前中兴通讯、美团架构师，现某互联网公司联系qq：184480602，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬学习必须往深处挖，挖的越深，基础越扎实！redis 是否使用了 raft 一致性算法呢？使用了，但不是严格意义上的 raft，然而 raft 算法的核心要点：领导者选举，日志复制，安全性，你都可以在 redis 中找到相似的实现。下面将探索一下 redis 关于 raft 算法的有关实现。
选举算法-redis集群
m0_37145844的博客
11-05 1075
Raft[编辑] 维基百科，自由的百科全书 跳到导航跳到搜索 关于木筏，请见“筏”。 Raft是一种用于替代Paxos的共识算法。相比于Paxos，Raft的目标是提供更清晰的逻辑分工使得算法本身能被更好地理解，同时它安全性更高，并能提供一些额外的特性。[1][2]:1Raft能为在计算机集群之间部署有限状态机提供一种通用方法，并确保集群内的任意节点在某种状态转换上保持一致。Raft算法的开源实现众多，在Go、C++、Java以及Scala中都有完整的代码实现。Raft这一名字来源于"Reli...
Redis中算法之——Raft算法
weixin_30949361的博客
01-17 1065
　　Sentinel系统选举领头的方法是对Raft算法的领头选举方法的实现。 　　在分布式系统中一致性是很重要的。1990年Leslie Lamport提出基于消息传递的一致性算法Paxos算法，解决分布式系统中就某个值或决议达成一致的问题。Paxos算法流程繁杂实现起来也比较复杂。 　　2013年斯坦福的Diego Ongaro、John Ousterhout两个人以易懂为目标设计一致性算法...
分布式理论(六)—— Raft 算法
你可路过我的倾城时光、
06-22 391
分布式理论(六)—— Raft 算法 前言 我们之前讲述了 Paxos 一致性算法，虽然楼主尝试用最简单的算法来阐述，但仍然还是有点绕。楼主最初怀疑自己太笨，后来才直到，该算法的晦涩难懂不是只有我一个人这么认为，而是国际公认！ 所以 Paxos 算法在 1990 就发表出来，但却得不到运用。真正的名声大噪还是在兰伯特使用 “更简单” 的方式重写了一篇论文才开始。 这些和今天说的 Raft ...
一起学Consul(3)——Raft算法
凤瓦力
05-17 1868
现在市面上的很多分布式系统所用的分布式一致性算法基本上都是采用的Raft算法，比如Redis集群、Redis哨兵系统、Consul集群等。还有其他分布式一致性算法，比如Paxos、ZAB（zookeeper atomic Broadcast）等。 首先，什么是分布式一致性？是指在分布式系统中，各个节点的状态如何达到一致的问题。如果数据只存储一份，那么天然是一致的，因为一份数据永远只有一个状态。为了...
08 Redis之集群的搭建和复制原理+哨兵机制+CAP定理+Raft算法
m0_46671240的博客
02-21 736
2.8版本之前, Redis采用主从集群模式. 实现了数据备份和读写分离2.8版本之后, Redis采用Sentinel哨兵集群模式 , 实现了集群的高可用。
【NoSQL数据库】Redis——哨兵模式
翡翠泪滴的博客
06-06 1593
Redis Sentinel，即Redis哨兵，在Redis 2.8版本开始引入。哨兵的核心功能是主节点的自动故障转移。哨兵机制（sentinel）是Redis解决高可用的一种解决方案：它是由一个或者多个sentinel 实例组成的一个sentinel 系统。
Redis(二) 哨兵节点、RAFT算法
qq_42766738的博客
08-27 2229
Redis的哨兵节点与选主策略
[redis 源码走读] raft 一致性算法
wenfh2020的专栏
12-02 993
raft 一致性算法，它是分布式系统中一种高可用算法策略。只单纯看论文算法，很难掌握它的工作流程，在 redis 里 raft 算法主要体现在：redis 主从数据复制 和 sentinel 故障转移，如果你有兴趣，可以研究对应 redis 源码，当这两个点理解了，raft 算法自然就理解了。 ???? 文章来源 《[redis 源码走读] raft 一致性算法》 1. 算法文档 raft 算法官网《The Raft Consensus Algorithm》（连接可能需要翻墙） raft 算法中文翻
浅谈redis sentinel raft 算法
lyzchengxuyuan的博客
02-26 1665
分布式一致性算法的诞生是为了解决多个节点之间数据一致性问题的。 LOG REPLICATION: 1、分布式环境中的三个状态：FOLLOWER、CANDIDATE、LEADER 2、LEADER ELECTION：当leader宕机或者是不可用之后就会出发新的leader选举，这就叫做 leader election 3、log replication: 在选举出新的leader时，由于此时所有的写操作日志还没有同步导其他的follower节点所以此时写操作日志处于未提交状态，当超过半数的follower节
Redis Raft算法：强一致性机制解析
最新发布
AIHacksCash的博客
09-04 769
在分布式系统中，数据一致性的保证是至关重要的。以Redis为例，作为一款高性能的键值存储系统，其数据一致性问题尤为突出。在分布式环境下，如何确保Redis集群中的数据强一致性，成为了开发者和运维人员关注的焦点。为了解决这一问题，Raft算法应运而生。想象一下，在一个大型分布式Redis集群中，由于网络分区、节点故障等原因，可能会导致数据不一致的情况。这种情况下，如果不对数据进行强一致性保证，那么可能会导致严重的业务错误，甚至影响到整个系统的稳定性。
raft算法
06-25 985
Raft算法包括三种角色: Leader (领导者)、 Candidate (候选领导者)和 Follower (眼随 者)，决策前通过选举一个全局的 leader 来简化后续的决策过程 。 Leader 角色十分关键，决定日志 (log)的提交 。 日志只能由 Leader 向 Follower 单向复制 。典型的过程包括以下两个主要阶段:口 Leader 选举:开始所有节点都是 Followe...
Redis学习笔记——Raft选举算法
weixin_45774053的博客
04-14 488
核心思想是通过的方式选择出一个主节点。
Raft算法
shendeguang的专栏
01-10 258
https://raft.github.io/
Redis分布式架构
08-29
<think>嗯，用户这次明确要求了解Redis分布式架构，但提供的引用资料有些混乱——前三条引用都是关于Redis的，而用户上一次讨论的却是Kafka架构。这可能是用户切换话题时忘记更新引用标签了。 用户身份推测：可能是后端开发工程师或系统架构师，正在对比不同消息队列和缓存系统的分布式方案。ta特意强调“参考站内引用”，说明需要权威的技术细节，而非泛泛而谈。 核心需求拆解： 1. 需要体系化的Redis分布式架构分类（主从/哨兵/集群） 2. 关注不同方案的适用场景和选择依据 3. 隐含比较需求——可能正在技术选型 技术要点优先级： 首先必须澄清引用混淆——用户给的[^1][^2][^3]实际对应Redis资料，需重新关联引用。然后重点展开： - 主从复制的异步特性与数据延迟风险[^1] - 哨兵自动故障转移的选举机制[^2] - Cluster槽位分片的数据路由算法[^3] 特别要注意用户上次深度讨论了Kafka的ISR机制，可能会对比Redis的主从同步差异。需要在“数据一致性”部分明确区别：Redis主从是异步复制，不像Kafka有ISR保障。 架构图选择：用mermaid展示Cluster分片逻辑最直观，因为用户上次对Kafka的分区机制表现出兴趣。同时补充哨兵监控状态的文本流程图，避免视觉冗余。 风险提示：用户可能忽略脑裂问题，需在哨兵和Cluster章节强调网络分区时的处理策略。最后用表格对比三种方案，帮助决策——这应该是ta的终极目标。</think>### Redis分布式架构深度解析 Redis分布式架构通过多种方案实现高可用、水平扩展和容错能力，核心方案包括主从复制、哨兵模式和Redis Cluster，以下是详细解析： ```mermaid graph TD A[Redis分布式架构] --> B[主从复制] A --> C[哨兵模式] A --> D[Redis Cluster] B --> E[读写分离] B --> F[数据冗余] C --> G[自动故障转移] C --> H[监控节点状态] D --> I[数据分片] D --> J[水平扩展] ``` --- #### 一、核心架构方案 1. **主从复制 (Replication)** - **架构**：1个主节点(Master) + N个从节点(Slave) - **数据流**： ```mermaid sequenceDiagram Master->>Slave1: 同步RDB快照 Master->>Slave2: 传播写命令 Note over Master,Slave2: 异步复制 ``` - **特性**： - 读写分离：写请求仅限主节点，读请求可分散到从节点 - 数据冗余：从节点保留全量数据副本 - **局限**：主节点单点故障（需人工干预）[^1] 2. **哨兵模式 (Sentinel)** - **组件**：奇数个哨兵节点（监控集群状态） - **核心能力**： - 自动故障检测（心跳机制） - 主节点故障时选举新主节点（基于Raft协议） - 客户端重定向（更新主节点地址） - **故障转移流程**： 1. 哨兵检测主节点失效（`+sdown`） 2. 仲裁确认（`+odown`） 3. 选举Leader哨兵 4. 执行主从切换（`+switch-master`）[^2] 3. **Redis Cluster (集群模式)** - **设计核心**： - **数据分片**：16384个槽位（Slot） $$Slot = CRC16(key) \mod 16384$$ - **去中心化**：节点间通过Gossip协议通信 - **多主架构**：每个分片含主节点+从节点 - **关键机制**： | 机制 | 说明 | |------------------|-----------------------------| | 重定向(MOVED) | 客户端访问错误分片时返回正确节点地址 | | 分片迁移 | 支持动态增删节点并重新分配槽位 | | 跨槽位操作限制 | 需用`Hash Tag`确保多key同分片 | [^3] --- #### 二、方案对比与选型指南 | 特性 | 主从复制 | 哨兵模式 | Redis Cluster | |---------------------|---------------|------------------------|--------------------| | **高可用** | 需人工干预 | 自动故障转移 | 自动故障转移 | | **水平扩展** | 不支持 | 不支持 | 支持动态扩缩容 | | **数据一致性** | 最终一致性 | 最终一致性 | 分区内强一致性 | | **适用场景** | 读密集型业务 | 中小规模生产环境 | 大规模分布式系统 | | **性能瓶颈** | 主节点写入瓶颈 | 哨兵选举延迟 | 跨分片事务限制 | --- #### 三、关键技术实现 1. **数据分区原理** - 哈希槽分配： ```python def assign_slot(key): slot = crc16(key) % 16384 return cluster_nodes[slot].master ``` - 优势：避免一致性哈希的数据倾斜问题 2. **故障检测机制** - 哨兵模式：每秒PING节点，超时（`down-after-milliseconds`）标记主观下线 - Cluster模式：节点间PING/PONG消息，半数节点确认失败则标记下线 3. **脑裂问题防护** - 最小从节点数：`min-replicas-to-write`（主节点需至少同步N个从节点才接受写） - 超时阈值：`cluster-node-timeout`（默认15秒）控制故障判定速度[^2] --- #### 四、典型应用场景 1. **主从复制**：缓存读扩展（电商商品页） 2. **哨兵模式**：会话存储、实时配置中心 3. **Redis Cluster**： - 全球购物车（分片存储用户数据） - 实时排行榜（利用`ZSET`分片计算） > **设计精髓**：通过$$数据局部性 = 分片 \times 副本 \times 协议$$的协同，平衡： > - 性能：单分片10万QPS[^3] > - 可用性：99.99% SLA > - 扩展性：支持PB级数据 ---
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值