说透 Nacos 一致性协议

这篇具有很好参考价值的文章主要介绍了说透 Nacos 一致性协议。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

1 Nacos ⼀致性协议

1.1 为什么 Nacos 需要⼀致性协议

Nacos尽可能减少用户部署以及运维成本,做到用户只需要⼀个程序包,就快速单机模式启动 Nacos 或集群模式启动 Nacos。而 Nacos 是⼀个需要存储数据的组件,为实现目标,就要在 Nacos 内部实现数据存储。单机问题不大,内嵌关系型数据库即可;但集群模式就要考虑保障各节点间的数据⼀致性及数据同步,就得引入共识算法,通过算法保障各节点间的数据⼀致性。

1.2 为什么 Nacos 选择了 Raft 以及 Distro

Nacos 在单个集群中同时运行 CP 协议及 AP 协议?要从 Nacos 场景出发:Nacos 集服务注册发现及配置管理于⼀体,集群下,各节点间的数据⼀致性保障问题,需拆分成两方面:

① 从服务注册发现来看

服务之间感知对方服务的当前可正常提供服务的实例信息,须从服务发现注册中心获取,因此对服务注册发现中心组件的可用性提出高要求,需在任何场景尽最大可能保证服务注册发现能力可以对外提供服务;同时 Nacos 的服务注册发现设计,采取了心跳可自动完成服务数据补偿的机制。如果数据丢失的话,是可以通过该机制快速弥补数据丢失。

为满足服务发现注册中心的可用性,强⼀致性共识算法不太合适,因为强⼀致性共识算法能否对外提供服务有要求,如当前集群可用节点数没过半,整个算法直接“罢工”,而最终⼀致共识算法更多保障服务可用性,并能保证在⼀定时间内各节点之间数据能达成⼀致。上述都是针对 Nacos 服务发现注册中的非持久化服务(即需客户端上报心跳进行服务实例续约)。

而对 Nacos 服务发现注册中的持久化服务,因为所有数据都是直接调用 Nacos服务端直接创建,因此需由 Nacos 保障数据在各节点间的强⼀致性,因此针对此类型的服务数据,选择强⼀致性共识算法来保障数据⼀致性。

② 配置管理

配置数据直接在 Nacos 服务端进行创建并管理,须保证大部分的节点都保存此配置数据,才能认为配置被成功保存,否则就会丢失配置的变更,问题很严重,如发布重要配置变更出现丢失变更,多半引起严重现网故障,因此对配置数据的管理,须集群中大部分节点强⼀致,这里只能使用强⼀致性共识算法。

③ 为啥是 Raft 和 Distro

强⼀致性共识算法,当前最多使用 Raft 协议,易让人理解,并有很多成熟工业算法实现,如蚂蚁金服 JRaft、Zookeeper ZAB、Consul Raft、百度 braft、Apache Ratis;因为 Nacos 是 Java 技术栈,因此只能在 JRaft、ZAB、ApacheRatis 中选择,但ZAB 和 Zookeeper 强绑定,再加上希望可以和 Raft 算法库支持团队随时沟通交流,因此选择 JRaft,也因为 JRaft 支持多 RaftGroup,为 Nacos 后面的多数据分片带来可能。

而 Distro 协议是阿里巴巴自研的⼀个最终⼀致性协议,最终⼀致性协议很多如 Gossip、Eureka 内的数据同步算法。Distro 算法集 Gossip 及 Eureka 协议优点并优化而出,原生 Gossip由于随机选取发送消息的节点,不可避免存在消息重复发给同⼀节点情况,增加网络传输的压力,也给消息节点带来额外的处理负载,而 Distro 算法引入权威 Server 概念,每个节点负责⼀部分数据及将自己的数据同步给其他节点,有效降低消息冗余问题。

2 早期的 Nacos ⼀致性协议

2.1 早期 Naocs 架构

说透 Nacos 一致性协议

特点

服务注册和配置管理⼀致性协议 分开,没下沉到 Nacos内核模块作为通用能力

  • 服务发现模块⼀致性协议的实现和服务注册发现模块的逻辑强耦合
  • 充斥服务注册发现的概念

缺点

  • Nacos 服务注册发现模块逻辑复杂难维护,耦合了⼀致性协议层的数据状态
  • 计算存储彻底难以分离
  • 对计算层的无限水平扩容能力也有影响

因此必然要对 Nacos⼀致性协议做抽象及下沉,使其成为 Core 模块能力,彻底让服务注册发现模块只充当计算能力,同时为配置模块去外部数据库存储打下架构基础。

3 当前 Nacos 的⼀致性协议层

当前 Nacos 内核中,已将⼀致性协议的能力完全下沉到内核模块作为 Nacos 核心能力,很好的服务于服务注册发现模块及配置管理模块。

3.1 当前 Nacos 的架构

说透 Nacos 一致性协议

特点

新 Nacos 架构将⼀致性协议从原先服务注册发现模块下沉到内核模块,并尽可能提供统⼀抽象接口,使上层的服务注册发现模块及配置管理模块,不再耦合任何⼀致性语义。

优点

解耦抽象分层后,每个模块能快速演进,并且性能和可用性都大幅提升。

4 Nacos 如何做到⼀致性协议下沉

既然 Nacos 将 AP、CP 协议下沉到内核模块:

说透 Nacos 一致性协议

且尽可能保持了⼀样的使用体验。那这⼀致性协议下沉如何做到的?

⼀致性协议抽象

其实,⼀致性协议,就是用来保证数据⼀致的,而数据的产生,必然有⼀个写入的动作;同时还要能够读数据,并且保证读数据的动作以及得到的数据结果,并且能够得到⼀致性协议的保障。因此,⼀致性协议最最基础的两个方法,就是写动作和读动作

public interface ConsistencyProtocol<T extends Config, P extends RequestProcessor> extends CommandOperations {
  
    /**
     * Obtain data according to the request.
     */
    Response getData(ReadRequest request) throws Exception;
    
    /**
     * 同步数据提交,在 Datum 中已携带相应的数据操作信息
     */
    Response write(WriteRequest request) throws Exception;
}

任何使用⼀致性协议的,只需使用 getData 及 write 方法。

⼀致性协议抽象在 consistency 包,Nacos 对 AP、CP ⼀致性协议接口使用抽象都在,且实现具体⼀致性协议时,采用插件可插拔,进⼀步将⼀致性协议具体实现逻辑和服务注册发现、配置管理两个模块解耦。

package com.alibaba.nacos.core.distributed;

/**
 * Conformance protocol management, responsible for managing the lifecycle of conformance protocols in Nacos.
 */
@SuppressWarnings("all")
@Component(value = "ProtocolManager")
public class ProtocolManager extends MemberChangeListener implements DisposableBean {
    
    private void initAPProtocol() {
        ApplicationUtils.getBeanIfExist(APProtocol.class, protocol -> {
            Class configType = ClassUtils.resolveGenericType(protocol.getClass());
            Config config = (Config) ApplicationUtils.getBean(configType);
            injectMembers4AP(config);
            protocol.init(config);
            ProtocolManager.this.apProtocol = protocol;
        });
    }
    
    private void initCPProtocol() {
        ApplicationUtils.getBeanIfExist(CPProtocol.class, protocol -> {
            Class configType = ClassUtils.resolveGenericType(protocol.getClass());
            Config config = (Config) ApplicationUtils.getBean(configType);
            injectMembers4CP(config);
            protocol.init(config);
            ProtocolManager.this.cpProtocol = protocol;
        });
    }
}

仅做完⼀致性协议抽象还不够:

  • 服务注册发现及配置管理还是要依赖⼀致性协议接口,在两个计算模块中耦合了带状态的接口
  • 虽然做了比较高度的⼀致性协议抽象,服务模块及配置模块却依然还是要在自己代码模块去显式处理⼀致性协议的读写请求逻辑
  • 需要自己去实现⼀个对接⼀致性协议的存储

服务发现及配置模块,更应专注数据使用及计算,而非数据咋存储、咋保障数据⼀致性,数据存储及多节点⼀致问题应交由存储层保证。

为了:

  • 降低⼀致性协议出现在服务注册发现及配置管理两模块的频次
  • 尽可能让⼀致性协议只在内核模块中感知

Nacos又做数据存储抽象。

5 数据存储抽象

⼀致性协议是为保证数据⼀致,如利用⼀致性协议实现存储,那服务模块以及配置模块,就由原来的依赖⼀致性协议接口转为依赖存储接口,而存储接口后面具体实现就比⼀致性协议丰富,且服务模块、配置模块也无需为直接依赖⼀致性协议而承担多余编码工作(快照、状态机实现、数据同步)。使这两模块可更专注自己核心逻辑。对于数据抽象,这里仅以服务注册发现模块为例:

package com.alibaba.nacos.core.storage.kv;

public interface KvStorage {
    
    enum KvType {
        /**
         * Local file storage.
         */
        File,
    
        /**
         * Local memory storage.
         */
        Memory,
    
        /**
         * RocksDB storage.
         */
        RocksDB,
    }
  // ...
}

由于 Nacos 的服务模块存储,更多是根据单或多个唯⼀ key 去执行点查,因此KV存储接口最适合。接口定义后,就是这KVStore具体实现。可直接将 KVStore 实现对接 Redis,DB或直接根据 Nacos 内核模块的⼀致性协议,在此基础之上,实现⼀个内存或者持久化的分布式强(弱)⼀致性 KV。

通过功能边界将 Nacos 进程进⼀步分离为计算逻辑层和存储逻辑层,计算层和存储层之间的交互仅通过薄薄数据操作胶水代码,就在单个 Nacos 进程里面实现计算、存储彻底分离。

说透 Nacos 一致性协议

存储层

进⼀步实现插件化的设计,对于中小公司且有运维成本要求的话,可以直接使用 Nacos 自带的内嵌分布式存储组件来部署⼀套 Nacos 集群。

服务实例数据以及配置数据的量级很大的话,并且本身有⼀套比较好的 Paas 层服务,那么完全可以复用已有的存储组件,实现 Nacos 的计算层与存储层彻底分离。

本文由博客一文多发平台 OpenWrite 发布!文章来源地址https://www.toymoban.com/news/detail-704844.html

到了这里,关于说透 Nacos 一致性协议的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

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

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

相关文章

  • AMBA ACE cache一致性协议(二)

    以下标绿色的为ACE新加信号。   ACE通道使用举例:   1)从Shareable locations,执行load操作 情景:master本地无此cacheline,但其他masetr的cache中有此cacheline(shareable) A。Master 在AR通道发起一个 read transaction  B。 interconnect确定(知道)其他的master caches谁有这个AR地址的数据。通过

    2024年02月08日
    浏览(40)
  • Zookeeper分布式一致性协议ZAB源码剖析

    ZAB 协议全称:Zookeeper Atomic Broadcast(Zookeeper 原子广播协议)。 Zookeeper 是一个为分布式应用提供高效且可靠的分布式协调服务。在解决分布式一致性方面,Zookeeper 并没有使用 Paxos ,而是采用了 ZAB 协议,ZAB是Paxos算法的一种简化实现。 ZAB 协议定义:ZAB 协议是为分布式协调服

    2024年02月07日
    浏览(52)
  • 聊聊分布式架构09——分布式中的一致性协议

    目录 01从集中式到分布式 系统特点 集中式特点 分布式特点 事务处理差异 02一致性协议与Paxos算法 2PC(Two-Phase Commit) 阶段一:提交事务请求 阶段二:执行事务提交 优缺点 3PC(Three-Phase Commit) 阶段一:CanCommit 阶段二:PreCommit 阶段三:doCommit 优缺点 Paxos算法 拜占庭将军问题

    2024年02月08日
    浏览(51)
  • 【ZooKeeper高手实战】ZAB协议:ZooKeeper分布式一致性的基石

    🌈🌈🌈🌈🌈🌈🌈🌈 欢迎关注公众号(通过文章导读关注:【11来了】),及时收到 AI 前沿项目工具及新技术 的推送 发送 资料 可领取 深入理解 Redis 系列文章结合电商场景讲解 Redis 使用场景 、 中间件系列笔记 和 编程高频电子书 ! 文章导读地址:点击查看文章导读!

    2024年02月03日
    浏览(46)
  • 一篇文章让你弄懂分布式一致性协议Paxos

    Paxos算法由Leslie Lamport在1990年提出,它是少数在工程实践中被证实的强一致性、高可用、去中心的分布式协议。Paxos协议用于在多个副本之间在有限时间内对某个决议达成共识。Paxos协议运行在允许消息重复、丢失、延迟或乱序,但没有拜占庭式错误的网络环境中,它利用“大

    2024年02月09日
    浏览(43)
  • 一致性广播、可靠广播、原子广播、安全因果原子广播以及与拜占庭协议结合

    在分布式系统中,广播协议是确保信息在网络中的节点之间有效传递的关键机制。一致性广播、可靠广播、原子广播和安全因果原子广播是分布式系统中用于确保消息传递和一致性的四种不同类型的广播协议。它们各自有不同的目标和特性,适用于不同的应用场景。本文是对

    2024年04月13日
    浏览(62)
  • 一文读懂从 CPU 多级缓存 & 缓存一致性协议(MESI)到 Java 内存模型

    参考:Java Memory Model 多级缓存的出现解决了CPU处理速度和内存读取速度不一致的问题,但是同时也带来缓存不一致的问题,为了解决这个问题,我们引入了缓存一致性协议,常见的缓存一致性协议有MSI,MESI,MOSI,Synapse,Firefly及DragonProtocol等等,下文以MESI协议进行讲述。 缓

    2024年02月05日
    浏览(72)
  • 一文通吃:从 ZooKeeper 一致性,Leader选举讲到 ZAB 协议与 PAXOS 算法(上)

    本文首发自「慕课网」,想了解更多IT干货内容,程序员圈内热闻,欢迎关注\\\"慕课网\\\"或慕课网公众号! 作者:大能 | 慕课网讲师 本文将从ZooKeeper集群如何保证一致性,讲到zookeeper保证数据一致性的协议,然后展开讲Zookeeper集群Leader选举,包括集群三种节点的类型,ZAB协议中

    2024年02月07日
    浏览(57)
  • 分布式「走进分布式一致性协议」从2PC、3PC、Paxos 到 ZAB

    设计一个分布式系统必定会遇到一个问题—— 因为分区容忍性(partition tolerance)的存在,就必定要求我们需要在系统可用性(availability)和数据一致性(consistency)中做出权衡 。这就是著名的 CAP 一致性(Consistency)是指多副本(Replications)问题中的数据一致性。关于分布式

    2024年02月03日
    浏览(66)
  • 什么是一致性哈希?一致性哈希是如何工作的?如何设计一致性哈希?

    如果你有 n 个缓存服务器,一个常见的负载均衡方式是使用以下的哈希方法: 服务器索引 = 哈希(键) % N ,其中 N 是服务器池的大小。 让我们通过一个例子来说明这是如何工作的。如表5-1所示,我们有4台服务器和8个字符串键及其哈希值。 为了获取存储某个键的服务器,我们

    2024年02月06日
    浏览(63)

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

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

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

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

二维码1

领取红包

二维码2

领红包