对标Eureka的AP一致性,Nacos如何实现Raft算法

一、快速了解Raft算法

Raft 适用于一个管理日志一致性的协议,相比于 Paxos 协议 Raft 更易于理解和去实现它。
为了提高理解性,Raft 将一致性算法分为了几个部分,包括领导选取(leader selection)、日志复制(log replication)、安全(safety),并且使用了更强的一致性来减少了必须需要考虑的状态。

相比Paxos,Raft算法理解起来更加直观。

Raft算法将Server划分为3种状态,或者也可以称作角色:

  • Leader
    负责Client交互和log复制,同一时刻系统中最多存在1个。
  • Follower
    被动响应请求RPC,从不主动发起请求RPC。
  • Candidate

一种临时的角色,只存在于leader的选举阶段,某个节点想要变成leader,那么就发起投票请求,同时自己变成candidate。如果选举成功,则变为candidate,否则退回为follower

状态或者说角色的流转如下:

在Raft中,问题分解为:领导选取、日志复制、安全和成员变化。

复制状态机通过复制日志来实现:

日志:每台机器保存一份日志,日志来自于客户端的请求,包含一系列的命令
状态机:状态机会按顺序执行这些命令
一致性模型:分布式环境下,保证多机的日志是一致的,这样回放到状态机中的状态是一致的

Raft算法选主流程

Raft中有Term的概念,Term类比中国历史上的朝代更替,Raft 算法将时间划分成为任意不同长度的任期(term)。

选举流程

1、follower增加当前的term,转变为candidate。
2、candidate投票给自己,并发送RequestVote RPC给集群中的其他服务器。
3、收到RequestVote的服务器,在同一term中只会按照先到先得投票给至多一个candidate。且只会投票给log至少和自身一样新的candidate。

关于Raft更详细的描述,可以查看这里,从分布式一致性到共识机制(二)Raft算法

二、Nacos中的CP一致性

Spring Cloud Alibaba Nacos 在 1.0.0 正式支持 AP 和 CP 两种一致性协议,其中的CP一致性协议实现,是基于简化的 Raft 的 CP 一致性。

如何实现Raft算法

Nacos server在启动时,会通过RunningConfig.onApplicationEvent()方法调用RaftCore.init()方法。

启动选举

public static void init() throws Exception {

    Loggers.RAFT.info("initializing Raft sub-system");

    // 启动Notifier,轮询Datums,通知RaftListener
    executor.submit(notifier);

    // 获取Raft集群节点,更新到PeerSet中
    peers.add(NamingProxy.getServers());

    long start = System.currentTimeMillis();

    // 从磁盘加载Datum和term数据进行数据恢复
    RaftStore.load();

    Loggers.RAFT.info("cache loaded, peer count: {}, datum count: {}, current term: {}",
        peers.size(), datums.size(), peers.getTerm());

    while (true) {
        if (notifier.tasks.size() <= 0) {
            break;
        }
        Thread.sleep(1000L);
        System.out.println(notifier.tasks.size());
    }

    Loggers.RAFT.info("finish to load data from disk, cost: {} ms.", (System.currentTimeMillis() - start));

    GlobalExecutor.register(new MasterElection()); // Leader选举
    GlobalExecutor.register1(new HeartBeat()); // Raft心跳
    GlobalExecutor.register(new AddressServerUpdater(), GlobalExecutor.ADDRESS_SERVER_UPDATE_INTERVAL_MS);

    if (peers.size() > 0) {
        if (lock.tryLock(INIT_LOCK_TIME_SECONDS, TimeUnit.SECONDS)) {
            initialized = true;
            lock.unlock();
        }
    } else {
        throw new Exception("peers is empty.");
    }

    Loggers.RAFT.info("timer started: leader timeout ms: {}, heart-beat timeout ms: {}",
        GlobalExecutor.LEADER_TIMEOUT_MS, GlobalExecutor.HEARTBEAT_INTERVAL_MS);
}

在init方法主要做了如下几件事:

  1. 获取Raft集群节点 peers.add(NamingProxy.getServers());
  2. Raft集群数据恢复 RaftStore.load();
  3. Raft选举 GlobalExecutor.register(new MasterElection());
  4. Raft心跳 GlobalExecutor.register(new HeartBeat());
  5. Raft发布内容
  6. Raft保证内容一致性

选举流程

其中,raft集群内部节点间是通过暴露的Restful接口,代码在 RaftController 中。
RaftController控制器是raft集群内部节点间通信使用的,具体的信息如下

POST HTTP://{ip:port}/v1/ns/raft/vote : 进行投票请求

POST HTTP://{ip:port}/v1/ns/raft/beat : Leader向Follower发送心跳信息

GET HTTP://{ip:port}/v1/ns/raft/peer : 获取该节点的RaftPeer信息

PUT HTTP://{ip:port}/v1/ns/raft/datum/reload : 重新加载某日志信息

POST HTTP://{ip:port}/v1/ns/raft/datum : Leader接收传来的数据并存入

DELETE HTTP://{ip:port}/v1/ns/raft/datum : Leader接收传来的数据删除操作

GET HTTP://{ip:port}/v1/ns/raft/datum : 获取该节点存储的数据信息

GET HTTP://{ip:port}/v1/ns/raft/state : 获取该节点的状态信息{UP or DOWN}

POST HTTP://{ip:port}/v1/ns/raft/datum/commit : Follower节点接收Leader传来得到数据存入操作

DELETE HTTP://{ip:port}/v1/ns/raft/datum : Follower节点接收Leader传来的数据删除操作

GET HTTP://{ip:port}/v1/ns/raft/leader : 获取当前集群的Leader节点信息

GET HTTP://{ip:port}/v1/ns/raft/listeners : 获取当前Raft集群的所有事件监听者
RaftPeerSet

心跳机制

Raft中使用心跳机制来触发leader选举。心跳定时任务是在GlobalExecutor 中,
通过 GlobalExecutor.register(new HeartBeat())注册心跳定时任务,具体操作包括:

  • 重置Leader节点的heart timeout、election timeout;
  • sendBeat()发送心跳包
 public class HeartBeat implements Runnable {
        @Override
        public void run() {
            try {

                if (!peers.isReady()) {
                    return;
                }

                RaftPeer local = peers.local();
                local.heartbeatDueMs -= GlobalExecutor.TICK_PERIOD_MS;
                if (local.heartbeatDueMs > 0) {
                    return;
                }

                local.resetHeartbeatDue();

                sendBeat();
            } catch (Exception e) {
                Loggers.RAFT.warn("[RAFT] error while sending beat {}", e);
            }

        }
}

简单说明了下Nacos中的Raft一致性实现,更详细的流程,可以下载源码,查看 RaftCore 进行了解。源码可以通过以下地址检出:

git clone https://github.com/alibaba/nacos.git

扫码关注公众号:架构进化论,获得第一手的技术资讯和原创文章

原文地址:https://www.cnblogs.com/binyue/p/12217312.html

时间: 2024-11-10 11:18:14

对标Eureka的AP一致性,Nacos如何实现Raft算法的相关文章

eureka的简单介绍,eureka单节点版的实现?eureka的自我保护?eureka的AP性,和CP性?

一.什么是eureka? // eureka是一个注册中心,实现了dubbo中zookeeper的效果! 二.实现eureka工程的搭建? 1.1 单节点版 1.1 zookeeper 和 eureka的区别? /* 1. zookeeper不会把自己注册到注册中心,但是eureka会! 2. 配置eureka 需要配置不能把自己注册到注册中心里面. 3. consumer 也不能把自己注册到注册中心. 4. 只要provider可以. */ 1.2 创建eureka工程 20190926-sp

搞懂分布式技术2:分布式一致性协议与Paxos,Raft算法

搞懂分布式技术2:分布式一致性协议与Paxos,Raft算法 2PC 由于BASE理论需要在一致性和可用性方面做出权衡,因此涌现了很多关于一致性的算法和协议.其中比较著名的有二阶提交协议(2 Phase Commitment Protocol),三阶提交协议(3 Phase Commitment Protocol)和Paxos算法. 本文要介绍的2PC协议,分为两个阶段提交一个事务.并通过协调者和各个参与者的配合,实现分布式一致性. 两个阶段事务提交协议,由协调者和参与者共同完成. 角色 XA概

理解分布式一致性与Raft算法

理解分布式一致性与Raft算法 永远绕不开的CAP定理 出于可用性及负载方面考虑,一个分布式系统中数据必然不会只存在于一台机器,一致性简单地说就是分布式系统中的各个部分保持数据一致 但让数据保持一致往往并不像看上去那么简单,假设我们有两台机器A与B,这时A更新了数据,A需要将更新的指令同步到B,如果A到B网络传输到B数据落地的总时间为500ms,那么这个500ms就是可能造成数据不一致的时间窗口,假如两台机器分属不同机房,甚至分属不同国家的机房,其时间窗口会更大,具体会造成什么影响呢? 举个栗子

分布式一致性算法:Raft 算法

Raft 算法是可以用来替代 Paxos 算法的分布式一致性算法,而且 raft 算法比 Paxos 算法更易懂且更容易实现.本文对 raft 论文进行翻译,希望能有助于读者更方便地理解 raft 的思想.如果对 Paxos 算法感兴趣,可以看我的另一篇文章:分布式系列文章--Paxos算法原理与推导 摘要Raft 是用来管理复制日志(replicated log)的一致性协议.它跟 multi-Paxos 作用相同,效率也相当,但是它的组织结构跟 Paxos 不同.这使得 Raft 比 Pax

分布式中的一致性算法之Raft算法

在实际应用中,对于分布式系统而言,遇到一致性问题,业界产生了许多经典的分布式一致性算法,以前项目中常的分布式一致性算法是2PC和Paxos,对于Raft算法只知其名,从未仔细理解过,直到今天和同事聊天时,突然被问到,Paxos与Raft的区别在哪?为什么我们项目中应用Paxos产生这么多问题,当初是否考虑过采用Raft算法?这一问,我的确没有回答上来,因为我从来没有思考过Raft在分布式数据库存储系统应该怎样应用.Raft算法虽然是在2013年才发表的,但目前应用非常广泛,甚至成为分布式一致性算

分布式系统一致性问题与Raft算法(下)

上一篇讲述了什么是分布式一致性问题,以及它难在哪里,liveness和satefy问题,和FLP impossibility定理.有兴趣的童鞋可以看看分布式系统一致性问题与Raft算法(上). 这一节主要介绍raft算法是如何解决分布式系统中一致性问题的.说起raft大家可能比较陌生,但zookeeper应该都比较熟悉了,zookeeper的ZAB协议可以说和raft算法是非常相似的. 再PS:本篇的重点是介绍raft算法的逻辑,所以有些细节会选择性得忽略,不然就太长了.对具体实现细节有兴趣的童

Go语言实现一致性哈希(Consistent Hashing)算法

一致性哈希可用于解决服务器均衡问题. 用Golang简单实现了下,并加入了权重.可采用合适的权重配合算法使用. package main //一致性哈希(Consistent Hashing) //author: Xiong Chuan Liang //date: 2015-2-20 import ( "fmt" "hash/crc32" "sort" "strconv" "sync" ) const DE

一致性哈希(consistent hashing)算法

文章同步发表在博主的网站朗度云,传输门:http://www.wolfbe.com/detail/201608/341.html 1.背景 我们都知道memcached服务器是不提供分布式功能的,memcached的分布式完全是由客户端来实现的.在部署memcached服务器集群时,我们需要把缓存请求尽可能分散到不同的缓存服务器中,这样可以使得所有的缓存空间都得到利用,而且可以降低单独一台缓存服务器的压力.     最简单的一种实现是,缓存请求时通过计算key的哈希值,取模后映射到不同的memc

分布式一致性思想描述及Paxos算法学习

在分布式的情况下,出于可用性(单点问题导致全部不可用)和规模性(单点支撑能力有限)的考虑,通过使用多个参与者提供服务. 如何保证通过多个参与者写入和读取的值相同,即分布式中的数据一致性,是一个复杂的问题. 为了保持一致性,一般是两种方案,一种是所有节点每个事务里都一致(强一致):另一种不是所有节点在每个事物里都完全一致,比如采用主节点先更新,其他节点追加式更新的模式. 强一致模式下,服务可能会因为等待所有节点的同步更新和反馈,服务变得非常慢或者中断.节点间不完全一致的模式,如果仅看一个节点,可能