Raft 思想在架构中实践

这篇具有很好参考价值的文章主要介绍了Raft 思想在架构中实践。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

Raft 诞生背景:

分布式存储系统通常通过维护多个副本来进行容错,提高系统的可用性。要实现此目标,就必须要解决分布式存储系统的最核心问题:维护多个副本的一致性。

首先需要解释一下什么是一致性(consensus),它是构建具有容错性(fault-tolerant)的分布式系统的基础。 在一个具有一致性的性质的集群里面,同一时刻所有的结点对存储在其中的某个值都有相同的结果,即对其共享的存储保持一致。集群具有自动恢复的性质,当少数结点失效的时候不影响集群的正常工作,当大多数集群中的结点失效的时候,集群则会停止服务(不会返回一个错误的结果)

高可用:

多副本架构是云原生的基础,也是高可用、分布式架构场景中常见的一种架构解决方案。对于应用服务、数据库、中间件服务来说高可用是一种共识追求的目标,很多公司也会有很多高可用衡量指标:

衡量指标:
  1. PRO。Recovery Point Objective (RPO),是灾难(或中断)可能导致的数据(事务)丢失的最长目标时间,与数据恢复点设置有关,主要指的是业务系统所能容忍的数据丢失量,由业 务连续性规划定义。RPO不宜过长,以免数据丢失过多。

  2. RTORecovery Time Objective (RTO) ,是灾难(或中断)后必须恢复业务流程的目标持续时间和服务级别, 主要指的是所能容忍的业务停止服务的最长时间,也就是从灾难发生到业务系统恢复服务功能所需要的最短时间周期。RTO不宜过长,以避免与业务连续性中断相关的不可接受的后果

  3. SLAService Level Agreements (SLA)指的是与用户协商好的可容忍数据修复时长,一般以“几个9”来衡量:

  4. 99%或2个9:相当于每年3天15小时36分钟的停机时间。

  5. 99.9%或3个9:相当于每年8小时45分36秒的停机时间。

  6. 99.99%或4个9:相当于每年52分34秒的停机时间。

  7. 99.999%或5个9:相当于每年约5分钟的停机时间。

热门组件使用 Raft案例:

TIDB
简介:

TiDB 是 NewSql 一款很火的数据库,解决了 Mysql 对于海量数据的处理缺陷以及横向扩展能力(分布式),在此基础上还同时拥有 ACID 的事务特性,如果之前使用过Mysql 那么学习使用 TiDB 基本没有什么学习成本

我们重点来说说 TiDB中的 TiKV,TiDB 也是采用了存算分离架构,TiKV 就是存储层。

TiKV架构

Raft 思想在架构中实践,后端技术,架构,架构

Placement Driver : Placement Driver (PD) 负责整个集群的管理调度。

Node : Node 可以认为是一个实际的物理机器,每个 Node 负责一个或者多个 Store。

Store : Store 使用 RocksDB 进行实际的数据存储,通常一个 Store 对应一块硬盘。

Region : Region 是数据移动的最小单元,对应的是 Store 里面一块实际的数据区间。每个 Region会有多个副本(replica),每个副本位于不同的 Store ,而这些副本组成了一个 Raft group。

Leader 节点的视角 Raft 副本同步
一阶段

Raft 思想在架构中实践,后端技术,架构,架构

在第一个阶段里,一份 Data 数据会被 RAFT 状态机转换为两份数据,一份数据转换为 Entries,然后落盘存储到 Disk,另一份数据转换为 Message,发送给其他 Follower 节点。

  1. 应用接受到请求 Data 信息

  2. 应用通过调用 RAFT 的 propose 接口将 Data 数据传递到 RAFT 状态机中去

  3. 应用调用 Ready 函数等待 从 RAFT 中获取 Ready 结构体,从 Ready 结构体中拿出 Entries 和 Message,分别进行落盘和转化为 MsgAppend 信息传递给 Follower。

  4. 应用还需要调用 advance 接口,来更新 RAFT 的内部状态,例如 Log index 信息,代表 Log Entries 已落盘。

二阶段

Raft 思想在架构中实践,后端技术,架构,架构

  1. Follower 收到 Message 进行处理后 (例如落盘) 会将 Entries 的确认信息 MsgAppend Response 发送回给 Leader,值得注意的是这个 Message 中含有 Follower 已接收的最新的 Log Entries Index。

  2. 当 Leader 收到 Follower 节点的 Message 确认信息后,将会调用 step 函数将 Message 传递到 RAFT,RAFT 就会更新 Follower 的状态信息,尤其重要的是各个 Follower 的 Log Index 信息。

  3. 应用调用 Ready 接口后,就会将大多数 Follower 确认的 Log Entries 放到 Ready 结构体,应用就会收到已确认的 Committed Entries,可以对其进行 Apply。

  4. 之后依然还要调用 advance 接口,更新 RAFT 模块的状态,例如更新 Apply Index 信息,代表已提交。

  5. 最后,Leader 在给 Follower 发送 HeartBeat Msg 的时候,会带着 Leader 的 Committed Index,以此来告知 Follower 对应的 Log Entries 已经被提交,Follower 可以进行对应的 Apply 流程了。

RocketMQ
简介:

在 RocketMQ 4.5 版本之前,RocketMQ 只有 Master/Slave 一种部署方式,一组 Broker 中有一个 Master,有零到多个 Slave,Slave 通过同步复制或异步复制方式去同步 Master 的数据。Master/Slave 部署模式,提供了一定的高可用性。

但这样的部署模式有一定缺陷。比如故障转移方面,如果主节点挂了还需要人为手动的进行重启或者切换,无法自动将一个从节点转换为主节点。因此,我们希望能有一个新的多副本架构,去解决这个问题。

新的多副本架构首先需要解决自动故障转移的问题,本质上来说是自动选主的问题。这个问题的解决方案基本可以分为两种:

  1. 利用第三方协调服务集群完成选主,比如 zookeeper 或者 etcd。这种方案会引入了重量级外部组件,加重部署,运维和故障诊断成本,比如在维护 RocketMQ 集群还需要维护 zookeeper 集群,并且 zookeeper 集群故障会影响到 RocketMQ 集群。

  2. 利用 raft 协议来完成一个自动选主,raft 协议相比前者的优点,是它不需要引入外部组件,自动选主逻辑集成到各个节点的进程中,节点之间通过通信就可以完成选主。

多副本同步架构:

 Raft 思想在架构中实践,后端技术,架构,架构

raft 协议是复制状态机的实现,这种模型应用到消息系统中就会存在问题。对于消息系统来说,它本身是一个中间代理,commitlog 的状态是系统最终的状态,并不需要状态机再去完成一次状态的构建。因此 DLedger 去掉了 raft 协议中状态机的部分,但基于 raft 协议保证 commitlog 是一致的,并且是高可用的。

副本复制流程:

Raft 思想在架构中实践,后端技术,架构,架构

在 DLedger 中,leader 向所有 follower 发送日志也是完全相互独立和并发的,leader 为每个 follower 分配一个线程去复制日志,并记录相应的复制的位点,然后再由一个单独的异步线程根据位点情况检测日志是否被复制到了多数节点上,返回给客户端响应。

短暂分区避免多主&频繁选主逻辑:Raft 思想在架构中实践,后端技术,架构,架构

如果出现上图的网络分区,n2 与集群中的其他节点发生了网络隔离,按照 raft 论文实现,n2 会一直请求投票,但得不到多数的投票,term 一直增大。一旦网络恢复后,n2 就会去打断正在正常复制的 n1 和 n3,进行重新选举。

为了解决这种情况,DLedger 的实现改进了 raft 协议,请求投票的过程分成了多个阶段,其中有两个重要阶段:WAIT_TO_REVOTE 和 WAIT_TO_VOTE_NEXT。

WAIT_TO_REVOTE 是初始状态,这个状态请求投票时不会增加 term。

WAIT_TO_VOTE_NEXT 则会在下一轮请求投票开始前增加 term。

对于图中 n2 情况,当有效的投票数量没有达到多数量时。可以将节点状态设置 WAIT_TO_REVOTE,term 不会增加。通过这个方法,提高了 Dledger 对网络分区的容忍性。

 文章来源地址https://www.toymoban.com/news/detail-606262.html

 

 

 

 

到了这里,关于Raft 思想在架构中实践的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 替代MySQL半同步复制,Meta技术团队推出MySQL Raft共识引擎

    作者:Anirban Rahut、Abhinav Sharma、Yichen Shen、Ahsanul Haque 原文链接:https://engineering.fb.com/2023/05/16/data-infrastructure/mysql-raft-meta/ 译者:ChatGPT 责编:张红月 MySQL Raft是MySQL数据库中一种基于Raft协议的分布式一致性复制机制。近日,Meta技术团队分享了他们基于Raft协议在数据库基础设施

    2024年02月05日
    浏览(41)
  • JAVA---后端开发中实现分页功能

    Java开发是一门广泛应用于各种软件系统和网络应用的重要技术。在实际开发中,经常需要处理大量的数据和结果集,而分页功能则成为了提高用户体验和系统性能的关键。分页是将大数据集按照固定大小划分成多页并逐页显示的过程,能够有效减少数据传输量和页面加载时间

    2024年02月07日
    浏览(40)
  • cool Node后端 中实现中间件的书写

    1.需求 在node后端中,想实现一个专门鉴权的文件配置,可以这样来解释 就是 有些接口需要token调用接口,有些接口不需要使用token 调用  这期来详细说明一下      什么是中间件中间件顾名思义是指在请求和响应中间,进行请求数据的拦截处理,数据校验,并且进行逻辑处理

    2024年02月20日
    浏览(44)
  • 三、CNNs网络架构-跨层连接思想的网络架构

     《A review of convolutional neural network architectures and their optimizations》论文指出随着网络架构的深入,梯度消失、爆炸或退化问题变得越来越严重。跨层连接的思想是解决现有问题的有效方案,允许网络在非相邻层之间传递信息。因此,在文中主要介绍了以下跨层连接思想的网络

    2024年02月06日
    浏览(42)
  • 后端服务器中实现MySQL数据库操作接口

    首先,在Node.js中连接MySQL数据库需要用到mysql模块。可以使用npm包管理器进行安装: 安装完成之后,在Node.js中引入mysql模块: 接着,可以使用mysql.createConnection()方法创建数据库连接。这个方法需要传入一些连接参数,比如主机名、用户名、密码、数据库名称等: 其中,host表

    2024年04月11日
    浏览(48)
  • 从架构设计思想出发看Flutter

    Flutter 是一种流行的移动应用程序开发框架,它的设计特点之一是可以使用单一代码库构建 iOS 和 Android 应用程序。然而,对于功能比较多、模块比较复杂的应用程序,仅凭单一的代码库就可能导致代码的复杂性和维护难度的增加。在这种情况下,通过合适的应用程序架构设计

    2024年02月07日
    浏览(74)
  • 整洁架构在前端的设计思想与应用实践

    对于每个软件系统,我们都可以通过行为和架构两个维度来体现它的实际价值。 行为是指系统实现的功能特性,一般是比较紧急的,需要按时上线。架构就是指系统架构,是重要的,但是并不总是特别紧急。因此导致我们常常忽视系统的架构价值,使得系统越来越难于理解、

    2024年02月08日
    浏览(44)
  • 快速理解DDD领域驱动设计架构思想-基础篇

    本文与大家一起学习并介绍领域驱动设计(Domain Drive Design) 简称DDD,以及为什么我们需要领域驱动设计,它有哪些优缺点,尽量用一些通俗易懂文字来描述讲解领域驱动设计,本篇并不会从深层大论述讲解落地实现,这些大家可以在了解入门后再去深层次学习探讨或在后续进阶

    2024年02月10日
    浏览(48)
  • Spring第三课,Lombok工具包下载,对应图书管理系统列表和登录界面的后端代码,分层思想

    目录 一、Lombok工具包下载 二、前后端互联的图书管理系统 规范  三、分层思想 三层架构: 1.表现层 2.业务逻辑层 3.数据层 这个工具包是为了做什么呢? 他是为了不去反复的设置setting and getting 而去产生的工具包 ⚠️工具包下载:推荐不要下载太新的(较高的),也不要太

    2024年02月05日
    浏览(42)
  • Linux驱动的软件架构(二):设备驱动的分层思想

    在Linux 2.6以后的设备驱动模型中,需关心总线、设备和驱动这3个实体,总线将设备和驱动绑定。在系统每注册一个设备的时候,会寻找与之匹配的驱动;相反的,在系统每注册一个驱动的时候,会寻找与之匹配的设备,而 匹配由总线完成 。 一个现实的Linux设备和驱动通常都

    2024年02月13日
    浏览(49)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包