网易一面：Eureka怎么AP？Nacos既CP又AP，怎么实现的？

朱雀 2024-02-29 04:30 82阅读 0赞

### 说在前面 ###

在40岁老架构师 尼恩的**读者交流群**(50+)中，最近有小伙伴拿到了一线互联网企业如网易、微博、阿里、汽车之家、极兔、有赞、希音、百度、滴滴的面试资格，遇到一几个很重要的面试题：

>  *  Eureka是AP还是CP？ 说说其集群数据一致性流程？
>  *  Nacos是AP还是CP？ 说说其集群数据一致性流程？

与之类似的、其他小伙伴遇到过的问题还有：

>  *  Eureka怎么AP？Nacos既CP又AP，怎么实现的？

所以，这里尼恩给大家做一下系统化、体系化的梳理，使得大家可以充分展示一下大家雄厚的 “技术肌肉”，**让面试官爱到 “不能自已、口水直流”**。

也一并把这个题目以及参考答案，收入咱们的 《[尼恩Java面试宝典PDF][Java_PDF]》V112版本，供后面的小伙伴参考，提升大家的 3高 架构、设计、开发水平。

> 《尼恩 架构笔记》《尼恩高并发三部曲》《尼恩Java面试宝典》的PDF，请到公号【技术自由圈】获取

#### 文章目录 ####

*   *  说在前面
     *  注册中心集群的数据一致性问题
     *   *  CAP定理
         *  微服务注册中心是AP还是CP
     *  Eureka 的数据同步方式
     *   *  多个副本之间的 复制方式
         *  Eureka 的Peer to Peer 模式同步过程
         *  循环复制问题
         *  总结一下，Eureka 的数据同步方式
     *  Nacos 满足AP，又满足CP
     *  快速了解Distro 协议
     *   *  Distro 节点新加入集群场景
         *  心跳场景
         *  写操作场景
         *  读操作场景
         *  总结一下，Distro 的数据同步
     *  快速了解Raft协议
     *   *  Raft算法选主流程
         *   *  1.Term
             *  2.RPC
             *  3.选举流程
             *  4.日志复制
         *  如何实现Raft算法
         *   *  启动选举
             *  选举流程
             *  心跳机制
     *  说在最后
     *  推荐阅读

### 注册中心集群的数据一致性问题 ###

服务注册中心必然是高可用的，这意味着它不能是单点的，而必须是一个注册中心集群。

接下来的问题是：

在一个微服务注册中心集群中，如何确保微服务 Provider 提供者的注册信息或元数据信息保持一致性？

首先，回顾一下CAP定理。

#### CAP定理 ####

分布式系统中有一个重要理论：CAP。

1.  **C：一致性**（Consistency）  
    在分布式系统中，数据会在多个副本中存在，一些问题可能导致在写入数据时，部分副本成功，部分副本失败，从而导致数据不一致。一致性 C 的要求是，数据更新操作成功后，多个副本的数据必须保持一致。
2.  **A：可用性**（Availability）  
    无论何时，客户端对集群进行读写操作，请求都应能得到正常的响应。
3.  **P：分区容错性**（Partition Tolerance）  
    当发生通信故障，集群被分割成多个无法通信的分区时，集群仍应能正常运行。

![44b39bb3d5184893a123bd40ce18cc40.png][]

#### 微服务注册中心是AP还是CP ####

回到微服务注册中心的场景。

微服务注册中心的中间件非常多，比如传统的分布式协调组件 Zookeeper， 比如 传统的微服务注册中心 Eureka，比如 阿里的微服务注册中心Nacos，还有 google的 分布式协调组件 etcd，等等。

微服务注册中心是AP还是CP？

首先要明确的是 Eureka 是AP 高并发类型，不是CP强一致类型，而是弱数据一致性的。

ZooKeeper 是CP类型的注册中心，就是尽可能的保证强数据一致性，ZooKeeper首先牺牲A，另外，在某些情况下可以牺牲可用性P。

所以， Eureka 与ZooKeeper 完全是两个极端。

Eureka 则选择了 A，ZooKeeper 优先选择了 C。

Eureka 具有高可用性，在任何时候，服务消费者都能正常获取服务列表，但不保证数据的强一致性，消费者可能会拿到过期的服务列表

Nacos 则做了兼容，既能支持AP模式，也能支持CP模式。

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

### Eureka 的数据同步方式 ###

#### 多个副本之间的 复制方式 ####

首先看看 数据同步的方式，或者说多个副本的 复制方式。  
通常，分布式系统中的数据在多个副本间的复制方式，大体上可以分为以下两种：

*  主从复制

这种是 Master-Slave 模式，存在一个 master 主副本，其他则是 Slave 从副本，所有的写操作都会被提交到主副本，然后由主副本更新到其他从副本。

因此，写压力都会聚集在主副本上，这成为了系统的瓶颈，而从副本则可以分担读请求。

*  对等复制

这种是 Peer to Peer 模式，副本之间不存在主从之分，任何一个副本都可以接收写操作，然后各个副本之间会相互进行数据更新。

Peer to Peer 对等复制模式的优势：

任何一个副本都可以接收写请求，不存在写压力的瓶颈，但是在各个副本间进行数据同步时可能会出现数据冲突。

Eureka 就是采用了 Peer to Peer 模式。

#### Eureka 的Peer to Peer 模式同步过程 ####

在 Eureka Server 启动之后，它会利用本地的 Eureka Client 向其他 Eureka Server 节点中的一个节点发起请求，以获取注册的服务信息，并将这些信息复制到其他 peer 节点。

每当 Eureka Server 的自身信息发生变化，例如微服务的客户端向它发起注册、续约或注销请求时，它会将最新的信息推送给其他 Eureka Server，以保持数据的同步性。

![b0f6ae4005d14f0981220a3f921f2604.png][]

#### 循环复制问题 ####

当然，这里有一个问题： 循环复制问题。

具体来说，如果自身的信息变更是由另一个 Eureka Server 同步过来的，那么如果再将这些信息同步回去，就会出现数据同步的死循环。

![8fbb0a30e4fd4e77a18703940f18cea4.png][]

在 Eureka Server 执行复制操作时，它会使用一个名为 HEADER\_REPLICATION 的 http header 来区分复制操作。

如果一个请求携带了 HEADER\_REPLICATION 这个 header，那么这个请求就不再是普通应用实例微服务的客户端的正常请求，而是来自其他 server 的复制请求。这样，当 Eureka Server 收到复制请求时，它就不会再执行复制操作，从而避免了死循环。

还有一个问题，就是数据冲突。

比如 server A 向 server B 发起同步请求，如果 A 的数据比 B 的还旧，那么 B 不可能接受 A 的数据。在这种情况下，B 如何知道 A 的数据是旧的呢？这时 A 又应该怎么办呢？

数据的新旧通常是通过版本号来定义的，Eureka 使用 lastDirtyTimestamp 这个类似版本号的属性来实现。

lastDirtyTimestamp 是注册中心中服务实例的一个属性，它表示此服务实例最近一次变更时间。

![123b417097154e7cb67d847b41517ab7.png][]

节点间的复制，可能会出错，如何进行错误的检测和弥补呢？

此外，Eureka 集群中，还有一个重要的机制：hearbeat 心跳，即续约操作，用于完成数据的最终修复。由于节点间复制可能出现错误，我们可以通过心 beat 机制来发现并修复这些错误。

#### 总结一下，Eureka 的数据同步方式 ####

*  Eureka 使用 Peer to Peer 模式进行数据复制。
 *  Eureka 通过 http header就是 HEADER\_REPLICATION 解决循环复制问题。
 *  Eureka 通过 lastDirtyTimestamp 解决复制冲突。
 *  Eureka 通过心跳机制实现数据修复。

### Nacos 满足AP，又满足CP ###

与Eureka 、Zookeeper集群不同Nacos 既能支持AP，又能支持 CP。

Nacos 支持 CP+AP 模式，这意味着 Nacos 可以根据配置识别为 CP 模式或 AP 模式，默认情况下为 AP 模式。

*  如果注册Nacos的client节点注册时ephemeral=true，那么Nacos集群对这个client节点的效果就是AP，采用distro协议实现；
 *  而注册Nacos的client节点注册时ephemeral=false，那么Nacos集群对这个节点的效果就是CP的，采用raft协议实现。

根据client注册时的属性，AP，CP同时混合存在，只是对不同的client节点效果不同。

因此，Nacos 能够很好地满足不同场景的业务需求。

### 快速了解Distro 协议 ###

Distro 协议是 Nacos 自主研发的一种 AP 分布式协议，专为临时实例设计，确保在部分 Nacos 节点宕机时，整个临时实例仍可正常运行。

作为一款具有状态的中间件应用的内置协议，Distro 确保了各 Nacos 节点在处理大量注册请求时的统一协调和存储。

Distro 协议 与Eureka Peer to Peer 模式同步过程， 大致是类似的。

Distro 协议的同步过程，大致如下：

*  每个节点是平等的都可以处理写请求，同时将新数据同步至其他节点。
 *  每个节点只负责部分数据，定时发送自己负责数据的校验值，到其他节点来保持数据⼀致性。
 *  每个节点独立处理读请求，并及时从本地发出响应。

接下来的几节将通过不同的场景介绍 Distro 协议的工作原理。

#### Distro 节点新加入集群场景 ####

新加入的 Distro 节点，会进行全量数据拉取。

具体操作是依次访问所有 Distro 节点，通过向其他机器发送请求，来拉取全量数据

![4f75991605024b4fb9f27e34890ac10c.png][]

在完成全量拉取操作后，Nacos 的每台机器都维护了当前所有注册的非持久化实例数据。

#### 心跳场景 ####

在 Distro 集群启动后，各台机器之间会定期发送心跳。

心跳信息主要包括各机器上的所有数据的元信息（使用元信息是为了确保网络中数据传输量维持在较低水平）。这种数据校验以心跳形式进行，即每台机器在固定时间间隔内向其他机器发起一次数据校验请求。

![0d494f243c19431fb39ebdfd9333f845.png][]

如果在数据校验过程中，某台机器发现其他机器上的数据与本地数据不一致，会发起一次全量拉取请求，将数据补全。

#### 写操作场景 ####

对于⼀个已经启动完成的 Distro 集群，在⼀次客户端发起写操作的流程中，当注册非持久化的实例的写请求打到某台 Nacos 服务器时，Distro 集群处理的流程图如下。

![5527b716226540f39d5d182fec95ccde.png][]

整个步骤包括几个部分（图中从上到下顺序）：

*  前置的 Filter 拦截请求，并根据请求中包含的 IP 和 port 信息计算其所属的 Distro 责任节点，并将该请求转发到所属的 Distro 责任节点上。
 *  责任节点上的 Controller 对写请求进行解析。
 *  Distro 协议定期执行 Sync 任务，将本机所负责的所有实例信息同步到其他节点上。

#### 读操作场景 ####

由于每台机器上都存储了全量数据，因此在每次读操作中，Distro 机器会直接从本地获取数据，实现快速响应。

![c674387ad5e9495f975aeb3802c973c6.png][]

这种机制确保了 Distro 协议可以作为 AP 协议，对读操作进行及时响应。

*  在网络分区状况下，所有读操作仍可正常返回结果；
 *  当网络恢复时，各 Distro 节点会将各数据片段进行合并恢复。

#### 总结一下，Distro 的数据同步 ####

Distro 协议是 Nacos 针对**临时实例数据**开发的⼀致性协议。

**数据存储在缓存中，并在启动时进行全量数据同步，定期执行数据校验**。

遵循 Distro 协议的设计理念，每个 Distro 节点均能接收读写请求。Distro 协议的请求场景主要分为以下三种情况：

1.  当该节点接收到**属于**该节点负责的实例的写请求时，直接写入。
2.  当该节点接收到**不属于**该节点负责的实例的写请求时，将在集群内部路由，**转发**给对应的节点，从而完成读写。
3.  当该节点接收到任何读请求时，**都直接在本机查询并返回**（因为所有实例都被同步到了每台机器上）。

作为 Nacos 的内置临时实例一致性协议，Distro 协议确保了在分布式环境中，每个节点上的服务信息状态能够及时通知其他节点，支持数十万量级服务实例的存储和一致性维护。

### 快速了解Raft协议 ###

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

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

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

![6c0b730b7bfc49b5b70735af60098061.png][]

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

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

日志：每台机器都保存一份日志，日志来源于客户端的请求，包含一系列的命令。

状态机：状态机会按顺序执行这些命令。

一致性模型：在分布式环境中，确保多台机器的日志保持一致，从而使状态机回放时的状态保持一致。

#### Raft算法选主流程 ####

Raft中使用心跳机制来出发leader选举。当服务器启动的时候，服务器成为follower。只要follower从leader或者candidate收到有效的RPCs就会保持follower状态。如果follower在一段时间内（该段时间被称为election timeout）没有收到消息，则它会假设当前没有可用的leader，然后开启选举新leader的流程。

##### 1.Term #####

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

任期用连续的数字进行表示。每一个任期的开始都是一次选举（election），一个或多个候选人尝试成为领导者。如果一个候选人赢得选举，它将在该任期的剩余时间内担任领导者。在某些情况下，选票可能会被平分，导致没有选出领导者，此时将开始新的任期并立即进行下一次选举。Raft 算法确保在给定的任期中只有一个领导者。

##### 2.RPC #####

Raft 算法中服务器节点之间通信使用远程过程调用（RPCs），并且基本的一致性算法只需要两种类型的 RPCs，为了在服务器之间传输快照增加了第三种 RPC。

RPC有三种：

*  **RequestVote RPC**：候选人在选举期间发起
 *  **AppendEntries RPC**：领导人发起的一种心跳机制，复制日志也在该命令中完成
 *  **InstallSnapshot RPC**：领导者使用该RPC来发送快照给太落后的追随者

##### 3.选举流程 #####

（1）follower增加当前的term，转变为candidate。

（2）candidate投票给自己，并发送RequestVote RPC给集群中的其他服务器。

（3）收到RequestVote的服务器，在同一个term中，只会按照先到先得投票给至多一个candidate。且只会投票给log至少和自身一样新的candidate。

![初始节点][8c3370c165834c029906e70ae31e8c4b.png]

![Node1 转为 Candidate 发起选举][Node1 _ Candidate]

![Node 确认选举][Node]

![Node1 成为 leader，发送 Heartbeat][Node1 _ leader_ Heartbeat]

candidate节点保持（2）的状态，直到下面三种情况中的一种发生。

*  该节点赢得选举，即收到大多数节点的投票，然后转变为 leader 状态。
 *  另一个服务器成为 leader，即收到合法心跳包（term 值大于或等于当前自身 term 值），然后转变为 follower 状态。
 *  一段时间后仍未确定胜者，此时会启动新一轮的选举。

为了解决当票数相同时无法确定 leader 的问题，Raft 使用随机选举超时时间。

##### 4.日志复制 #####

日志复制（Log Replication）的主要目的是确保节点的一致性，在此阶段执行的操作都是为了确保一致性和高可用性。

当 Leader 选举产生后，它开始负责处理客户端的请求。所有的事务（更新操作）请求都必须先由 Leader 处理。日志复制（Log Replication）就是为了确保执行相同的操作序列所做的工作。

在 Raft 中，当接收到客户端的日志（事务请求）后，先把该日志追加到本地的Log中，然后通过heartbeat把该Entry同步给其他Follower，Follower接收到日志后记录日志然后向Leader发送ACK，当Leader收到大多数（n/2+1）Follower的ACK信息后将该日志设置为已提交并追加到本地磁盘中，通知客户端并在下个heartbeat中Leader将通知所有的Follower将该日志存储在自己的本地磁盘中。

#### 如何实现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

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xlcmVhZA_size_16_color_FFFFFF_t_70][]

### 说在最后 ###

注册中心的 数据一致性 相关面试题，是非常常见的面试题。

以上的内容，如果大家能对答如流，如数家珍，基本上 面试官会被你 震惊到、吸引到。

在面试之前，建议大家系统化的刷一波 5000页《[尼恩Java面试宝典PDF][Java_PDF]》，并且在刷题过程中，如果有啥问题，大家可以来 找 40岁老架构师尼恩交流。

最终，**让面试官爱到 “不能自已、口水直流”**。offer， 也就来了。

### 推荐阅读 ###

《[百亿级访问量，如何做缓存架构设计][Link 1]》

《[多级缓存 架构设计][Link 2]》

《[消息推送 架构设计][Link 3]》

《[阿里2面：你们部署多少节点？1000W并发，当如何部署？][2_1000W]》

《[美团2面：5个9高可用99.999%，如何实现？][2_5_9_99.999]》

《[网易一面：单节点2000Wtps，Kafka怎么做的？][2000Wtps_Kafka]》

《[字节一面：事务补偿和事务重试，关系是什么？][Link 4]》

《[网易一面：25Wqps高吞吐写Mysql，100W数据4秒写完，如何实现？][25Wqps_Mysql_100W_4]》

《[亿级短视频，如何架构？][Link 5]》

《[炸裂，靠“吹牛”过京东一面，月薪40K][40K]》

《[太猛了，靠“吹牛”过顺丰一面，月薪30K][30K]》

《[炸裂了…京东一面索命40问，过了就50W+][40_50W]》

《[问麻了…阿里一面索命27问，过了就60W+][27_60W]》

《[百度狂问3小时，大厂offer到手，小伙真狠！][3_offer]》

《[饿了么太狠：面个高级Java，抖这多硬活、狠活][Java]》

《[字节狂问一小时，小伙offer到手，太狠了！][offer]》

《[收个滴滴Offer：从小伙三面经历，看看需要学点啥？][Offer]》

> 《尼恩 架构笔记》《尼恩高并发三部曲》《尼恩Java面试宝典》PDF，请到下面公号【技术自由圈】取↓↓↓

[Java_PDF]: https://blog.csdn.net/crazymakercircle/article/details/132927258
[44b39bb3d5184893a123bd40ce18cc40.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/29/d7262bc85008425c95c24fb543014a6e.png
[b0f6ae4005d14f0981220a3f921f2604.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/29/0200048f7bf94ed8a0bc5906c04bcbb9.png
[8fbb0a30e4fd4e77a18703940f18cea4.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/29/970431726b154fd095c257d1c8625e62.png
[123b417097154e7cb67d847b41517ab7.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/29/d3d8c9175ab44e3cb664106ddd5f5ffd.png
[4f75991605024b4fb9f27e34890ac10c.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/29/26efbb17f05a43a58c758c75f889300f.png
[0d494f243c19431fb39ebdfd9333f845.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/29/45a7f17b641947dbbfb7dfcc2b5cef0b.png
[5527b716226540f39d5d182fec95ccde.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/29/bc3108e8f6324caf9a4a14db9d68a4b5.png
[c674387ad5e9495f975aeb3802c973c6.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/29/12487fa93d5d4ad484dad7e6c2b9338b.png
[6c0b730b7bfc49b5b70735af60098061.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/29/99f93d0eaca24f5592488acb962edd25.png
[8c3370c165834c029906e70ae31e8c4b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/29/6b5e5f0813a240bc9edff6db87f559ec.png
[Node1 _ Candidate]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/29/a8cb6d19f1614b62a8da9f59d58e37f3.png
[Node]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/29/92851e6c3d4d4d91b49ee4c30887bed4.png
[Node1 _ leader_ Heartbeat]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/29/c09940417702427eb4877e8dc9e34f54.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xlcmVhZA_size_16_color_FFFFFF_t_70]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/29/abda221c9b8048e4a6aa1087ab8e3e24.png
[Link 1]: https://blog.csdn.net/crazymakercircle/article/details/132628780
[Link 2]: https://blog.csdn.net/crazymakercircle/article/details/132637261
[Link 3]: https://blog.csdn.net/crazymakercircle/article/details/132561087
[2_1000W]: https://blog.csdn.net/crazymakercircle/article/details/132526730
[2_5_9_99.999]: https://blog.csdn.net/crazymakercircle/article/details/132509763
[2000Wtps_Kafka]: https://blog.csdn.net/crazymakercircle/article/details/132479866
[Link 4]: https://blog.csdn.net/crazymakercircle/article/details/132456546
[25Wqps_Mysql_100W_4]: https://blog.csdn.net/crazymakercircle/article/details/132403212
[Link 5]: https://blog.csdn.net/crazymakercircle/article/details/132379306
[40K]: https://blog.csdn.net/crazymakercircle/article/details/132150378
[30K]: https://blog.csdn.net/crazymakercircle/article/details/132000420
[40_50W]: https://blog.csdn.net/crazymakercircle/article/details/131615296
[27_60W]: https://blog.csdn.net/crazymakercircle/article/details/131147192
[3_offer]: https://blog.csdn.net/crazymakercircle/article/details/131027012
[Java]: https://blog.csdn.net/crazymakercircle/article/details/130989697
[offer]: https://blog.csdn.net/crazymakercircle/article/details/130956376
[Offer]: https://blog.csdn.net/crazymakercircle/article/details/129317821