• 工作原理及RAFT算法详解

    • Leader选举：包括Raft 状态机和Raft算法中的Term（任期）两部分。
    • Raft 状态机
    • 1、Leader(领导者):

  • 2、Follower(跟随者):

  • 3、Candidate(候选者):

  • Raft算法中的Term（任期）

  • 日志复制【数据复制】

  • 安全性【数据安全】

  • etcd应用场景

    • 服务发现

  • 消息发布与订阅（配置中心）

  • 负载均衡（集群管理）

  • 分布式锁

  • 分布式队列

  • 集群监控与LEADER竞选

  • etcd启动参数详解

    • 端口说明

  • 参数使用方式

  • 成员标志【member flags】

  • 群集标志【clustering flags】

  • 代理标志【proxy flags】

  • 安全标志【security flags】

  • 日志标志【logging flags】

  • 不安全标志【unsafe flags】

  • 身份验证标志【auth flags】

  • 分析标志【profiling flags】

  • 实验标志【experimental flags】

  • etcd常用v3命令与参数

    • etcd V3命令

  • etcd V3命令全局参数

Kubernetes的核心组件ETCD介绍

====================================================================================

  • Etcd是一个高可用的键值存储系统，主要用于共享配置和服务发现，它通过Raft一致性算法处理日志复制以保证强一致性，我们可以理解它为一个高可用强一致性的服务发现存储仓库。

  • 在kubernetes集群中，etcd主要用于配置共享和服务发现

  • Etcd主要解决的是分布式系统中数据一致性的问题，而分布式系统中的数据分为控制数据和应用数据，etcd处理的数据类型为控制数据，对于很少量的应用数据也可以进行处理。

ETCD的主要功能

  • 基本的key-value存储

  • 监听机制

  • key的过期及续约机制，用于监控和服务发现

  • 原子CAS和CAD，用于分布式锁和leader选举

特点【优点】

  • 简单: curl可访问的用户的API（HTTP+JSON）

  • 安全: 可选的SSL客户端证书认证

  • 快速: 单实例每秒 1000 次写操作

  • 可靠: 使用Raft保证一致性

Etcd集群中的术语

| 关键词 | 解释 |

| — | — |

| Raft etcd | 所采用的保证分布式系统强一致性的算法。 |

| Node | 一个Raft状态机实例。 |

| Member | 一个etcd实例。它管理着一个Node，并且可以为客户端请求提供服务。 |

| Cluster | 由多个Member构成可以协同工作的etcd集群。 |

| Peer | 对同一个etcd集群中另外一个Member的称呼。 |

| Client | 向etcd集群发送HTTP请求的客户端。 |

| WAL | 预写式日志，etcd用于持久化存储的日志格式。 |

| snapshot | etcd防止WAL文件过多而设置的快照，存储etcd数据状态。 |

| Proxy | etcd的一种模式，为etcd集群提供反向代理服务。 |

| Leader | Raft算法中通过竞选而产生的处理所有数据提交的节点。 |

| Follower | 竞选失败的节点作为Raft中的从属节点，为算法提供强一致性保证。 |

| Candidate | 当Follower超过一定时间接收不到Leader的心跳时转变为Candidate开始Leader竞选。 |

| Term | 某个节点成为Leader到下一次竞选开始的时间周期，称为一个Term。 |

| Index | 数据项编号。Raft中通过Term和Index来定位数据。 |

Etcd的架构与术语

=========================================================================

流程分析

在这里插入图片描述

通常一个用户的请求发送过来，会经过HTTP Server转发给Store进行具体的事务处理，如果涉及到节点的修改，则需要交给Raft模块进行状态的变更，日志的记录。

然后再同步给别的etcd节点确认数据提交，最后进行数据提交，再次同步。

Etcd主要分为四个部分【http server、store、raft、WAL】

  • HTTP Server： 用于处理用户发送的API请求以及其他etcd节点的同步与心跳信息请求

  • Store: 用于处理 etcd 支持的各类功能的事务，包括数据索引、节点状态变更、监控与反馈、事件处理与执行等等，是 etcd 对用户提供的大多数 API 功能的具体实现。

  • Raft： Raft 强一致性算法的具体实现，是 etcd 的核心。

  • WAL：Write Ahead Log（预写式日志/日志先行），是 etcd 的数据存储方式，也是一种实现事务日志的标准方法。etcd通过 WAL 进行持久化存储，所有的数据提交前都会事先记录日志。Snapshot 是为了防止数据过多而进行的状态快照；Entry 表示存储的具体日志内容。

工作原理及RAFT算法详解

  • Etcd使用Raft协议来维护集群内各个节点状态的一致性。简单说，ETCD集群是一个分布式系统，由多个节点相互通信构成整体对外服务，每个节点都存储了完整的数据，并且通过Raft协议保证每个节点维护的数据是一致的。

  • Raft算法

  • Raft 是一种为了管理复制日志的一致性算法。它提供了和 Paxos 算法相同的功能和性能，但是它的算法结构和 Paxos 不同，使得 Raft 算法更加容易理解并且更容易构建实际的系统。一致性算法允许一组机器像一个整体一样工作，即使其中一些机器出现故障也能够继续工作下去。正因为如此，一致性算法在构建可信赖的大规模软件系统中扮演着重要的角色。

  • Raft算法分为三部分，分别是Leader选举、日志复制和安全性。

Leader选举：包括Raft 状态机和Raft算法中的Term（任期）两部分。

Raft 状态机

  • Raft集群中的每个节点都处于一种基于角色的状态机中。具体来说，Raft定义了节点的三种角色： Follower、Candidate和Leader。

  • 这三种角色状态之间的转换，如下图：

在这里插入图片描述

1、Leader(领导者):

Leader节点在集群中有且仅能有一个，它负责向所有的Follower节点同步日志数据。

2、Follower(跟随者):

Follower节点从Leader节点获取日志，提供数据查询功能，并将所有修改请求转发给Leader节点。（注意：由于proxy模式的本职就是启一个HTTP代理服务器，所以Etcd的代理节点（proxy）即作为Proxy角色的节点不会参与Leader的选举，只是将所有接收到的用户查询和修改请求转发到任意一个Follower或者Leader节点上。）

3、Candidate(候选者):

当集群中的Leader节点不存在或者失联之后，其他Follower节点转换为Candidate，然后开始新的Leader节点选举。

Raft算法中的Term（任期）

Raft会把时间分割成任意长度的任期，并且任期用连续的整数来标记。每一段任期都是从一次选举开始，一个或者多个候选人尝试成为领导者。如果一个候选人赢得选举，然后他就会在接下来的任期中充当Leader的职责。在某些情况下，一次选举会造成选票瓜分，这样，这一个任期将没有Leader。如果没有Leader，那么新的一轮选举就马上开始，也就是新的任期就会开始。Raft保证了在一个Term任期内，有且只有一个Leader。

在这里插入图片描述

日志复制【数据复制】

  • 是指主节点将每次操作形成日志条目，并持久化到本地磁盘，然后通过网络IO发送给其他节点。

  • 一旦一个领导人被选举出来，他就开始为客户端提供服务。客户端的每一个请求都包含一条被复制状态机执行的指令。领导人把这条指令作为一条新的日志条目附加到日志中去，然后并行的发起附加条目 RPCs 给其他的服务器，让他们复制这条日志条目。

  • Raft 算法保证所有已提交的日志条目都是持久化的并且最终会被所有可用的状态机执行。当主节点收到包括自己在内超过半数节点成功返回，那么认为该日志是可提交的(committed），并将日志输入到状态机，将结果返回给客户端。

  • 在正常的操作中，领导人和跟随者的日志保持一致性，所以附加日志 RPC 的一致性检查从来不会失败。然而，领导人崩溃的情况会使得日志处于不一致的状态（老的领导人可能还没有完全复制所有的日志条目）。这种不一致问题会在一系列的领导人和跟随者崩溃的情况下加剧。跟随者的日志可能和新的领导人不同的方式。跟随者可能会丢失一些在新的领导人中有的日志条目，他也可能拥有一些领导人没有的日志条目，或者两者都发生。丢失或者多出日志条目可能会持续多个任期。这就引出了另一个部分，就是安全性。

安全性【数据安全】

  • 选主以及日志复制并不能保证节点间数据一致。试想，当一个某个节点挂掉了，一段时间后再次重启，并当选为主节点。而在其挂掉这段时间内，集群若有超过半数节点存活，集群会正常工作，那么会有日志提交。这些提交的日志无法传递给挂掉的节点。当挂掉的节点再次当选主节点，它将缺失部分已提交的日志。在这样场景下，按Raft协议，它将自己日志复制给其他节点，会将集群已经提交的日志给覆盖掉。这显然是错误的。

  • 其他协议解决这个问题的办法是，新当选的主节点会询问其他节点，和自己数据对比，确定出集群已提交数据，然后将缺失的数据同步过来。这个方案有明显缺陷，增加了集群恢复服务的时间（集群在选举阶段不可服务），并且增加了协议的复杂度。Raft解决的办法是，在选主逻辑中，对能够成为主的节点加以限制，确保选出的节点已定包含了集群已经提交的所有日志。如果新选出的主节点已经包含了集群所有提交的日志，那就不需要从和其他节点比对数据了。简化了流程，缩短了集群恢复服务的时间。

etcd应用场景

=======================================================================

  • etcd应用场景很多，主要的有以下六种：

  • 服务发现

  • 消息发布与订阅（配置中心）

  • 负载均衡（集群管理）

  • 分布式锁、分布式队列

  • 集群监控

  • LEADER竞选。

服务发现

  • 服务发现要解决的也是分布式系统中最常见的问题之一，即在同一个分布式集群中的进程或服务，要如何才能找到对方并建立连接。本质上来说，服务发现就是想要了解集群中是否有进程在监听 udp 或 tcp 端口，并且通过名字就可以查找和连接。要解决服务发现的问题，需要具备以下三点：

  • 1.一个强一致性、高可用的服务存储目录。基于 Raft 算法的 etcd 天生就是这样一个强一致性高可用的服务存储目录。

  • 2.一种注册服务和监控服务健康状态的机制。用户可以在 etcd 中注册服务，并且对注册的服务设置key TTL，定时保持服务的心跳以达到监控健康状态的效果。

  • 3.一种查找和连接服务的机制。通过在 etcd 指定的主题下注册的服务也能在对应的主题下查找到。为了确保连接，我们可以在每个服务机器上都部署一个 Proxy 模式的 etcd，这样就可以确保能访问 etcd 集群的服务都能互相连接。

  • 例如随着 Docker 容器的流行，多种微服务共同协作，构成一个相对功能强大的架构的案例越来越多。透明化的动态添加这些服务的需求也日益强烈。通过服务发现机制，在 etcd 中注册某个服务名字的目录，在该目录下存储可用的服务节点的 IP。在使用服务的过程中，只要从服务目录下查找可用的服务节点去使用即可。

消息发布与订阅（配置中心）

  • 在分布式系统中，最为适用的组件间通信方式是消息发布与订阅机制。

  • 具体而言，即构建一个配置共享中心，数据提供者在这个配置中心发布消息，而消息使用者则订阅他们关心的主题，一旦相关主题有消息发布，就会实时通知订阅者。

  • 通过这种方式可以实现分布式系统配置的集中式管理与实时动态更新。

负载均衡（集群管理）

  • 利用etcd维护一个负载均衡节点表。etcd可以监控一个集群中多个节点的状态，当有一个请求发过来后，可以轮询式地把请求转发给存活着的多个节点。

  • 类似KafkaMQ，通过Zookeeper来维护生产者和消费者的负载均衡。同样也可以用etcd来做Zookeeper的工作

分布式锁

  • 因为etcd使用Raft算法保持了数据的强一致性，某次操作存储到集群中的值必然是全局一致的，所以很容易实现分布式锁。

  • 锁服务有以下两种使用方式：

  • 保持独占，即所有试图获取锁的用户最终只有一个可以得到。etcd为此提供了一套实现分布式锁原子操作CAS（CompareAndSwap）的API。通过设置prevExist值，可以保证在多个节点同时创建某个目录时，只有一个成功，而该用户即可认为是获得了锁。

  • 控制时序，即所有试图获取锁的用户都会进入等待队列，获得锁的顺序是全局唯一的，同时决定了队列执行顺序。etcd为此也提供了一套API（自动创建有序键），对一个目录建值时指定为POST动作，这样etcd会自动在目录下生成一个当前最大的值为键，存储这个新的值（客户端编号）。同时还可以使用API按顺序列出所有当前目录下的键值。此时这些键的值就是客户端的时序，而这些键中存储的值可以是代表客户端的编号。

分布式队列

  • 在保证队列达到某个条件时再统一按顺序执行。这种方法的实现可以在/queue这个目录中另外建立一个/queue/condition节点。

  • condition可以表示队列大小。比如一个大的任务需要很多小任务就绪的情况下才能执行，每次有一个小任务就绪，就给这个condition数字加1，直到达到大任务规定的数字，再开始执行队列里的一系列小任务，最终执行大任务。

  • condition可以表示某个任务在不在队列。这个任务可以是所有排序任务的首个执行程序，也可以是拓扑结构中没有依赖的点。通常，必须执行这些任务后才能执行队列中的其他任务。

  • condition还可以表示其它的一类开始执行任务的通知。可以由控制程序指定，当condition出现变化时，开始执行队列任务。

集群监控与LEADER竞选

  • 通过etcd来进行监控实现起来非常简单并且实时性强，用到了以下两点特性。

  • Watcher机制，当某个节点消失或有变动时，Watcher会第一时间发现并告知用户。

节点可以设置TTL key，比如每隔30s向etcd发送一次心跳使代表该节点仍然存活，否则说明节点消失。

这样就可以第一时间检测到各节点的健康状态，以完成集群的监控要求。

etcd启动参数详解

=========================================================================

端口说明

  • 2379和2380为etcd在IANA 的注册端口【为默认端口】，以前为私有端口4001和7001。

  • 2379:为客户端提供通讯

  • 2380:为服务器间提供通讯

参数使用方式

  • 下面所有参数的配置文件为：/etc/etcd/etcd.conf【需要安装etcd以后才会自动生成该文件】

  • 如下，是默认的参数

[root@etcd1 etcd]# cat /etc/etcd/etcd.conf

#[Member]

#ETCD_CORS=“”

ETCD_DATA_DIR=“/var/lib/etcd/default.etcd”

#ETCD_WAL_DIR=“”

#ETCD_LISTEN_PEER_URLS=“http://localhost:2380”

ETCD_LISTEN_CLIENT_URLS=“http://localhost:2379”

#ETCD_MAX_SNAPSHOTS=“5”

#ETCD_MAX_WALS=“5”

ETCD_NAME=“default”

#ETCD_SNAPSHOT_COUNT=“100000”

#ETCD_HEARTBEAT_INTERVAL=“100”

#ETCD_ELECTION_TIMEOUT=“1000”

#ETCD_QUOTA_BACKEND_BYTES=“0”

#ETCD_MAX_REQUEST_BYTES=“1572864”

#ETCD_GRPC_KEEPALIVE_MIN_TIME=“5s”

#ETCD_GRPC_KEEPALIVE_INTERVAL=“2h0m0s”

#ETCD_GRPC_KEEPALIVE_TIMEOUT=“20s”

#[Clustering]

#ETCD_INITIAL_ADVERTISE_PEER_URLS=“http://localhost:2380”

ETCD_ADVERTISE_CLIENT_URLS=“http://localhost:2379”

#ETCD_DISCOVERY=“”

#ETCD_DISCOVERY_FALLBACK=“proxy”

#ETCD_DISCOVERY_PROXY=“”

#ETCD_DISCOVERY_SRV=“”

#ETCD_INITIAL_CLUSTER=“default=http://localhost:2380”

#ETCD_INITIAL_CLUSTER_TOKEN=“etcd-cluster”

#ETCD_INITIAL_CLUSTER_STATE=“new”

#ETCD_STRICT_RECONFIG_CHECK=“true”

#ETCD_ENABLE_V2=“true”

#[Proxy]

#ETCD_PROXY=“off”

#ETCD_PROXY_FAILURE_WAIT=“5000”

#ETCD_PROXY_REFRESH_INTERVAL=“30000”

#ETCD_PROXY_DIAL_TIMEOUT=“1000”

#ETCD_PROXY_WRITE_TIMEOUT=“5000”

#ETCD_PROXY_READ_TIMEOUT=“0”

#[Security]

#ETCD_CERT_FILE=“”

#ETCD_KEY_FILE=“”

#ETCD_CLIENT_CERT_AUTH=“false”

#ETCD_TRUSTED_CA_FILE=“”

#ETCD_AUTO_TLS=“false”

#ETCD_PEER_CERT_FILE=“”

#ETCD_PEER_KEY_FILE=“”

#ETCD_PEER_CLIENT_CERT_AUTH=“false”

#ETCD_PEER_TRUSTED_CA_FILE=“”

#ETCD_PEER_AUTO_TLS=“false”

#[Logging]

#ETCD_DEBUG=“false”

#ETCD_LOG_PACKAGE_LEVELS=“”

#ETCD_LOG_OUTPUT=“default”

#[Unsafe]

#ETCD_FORCE_NEW_CLUSTER=“false”

#[Version]

#ETCD_VERSION=“false”

#ETCD_AUTO_COMPACTION_RETENTION=“0”

#[Profiling]

#ETCD_ENABLE_PPROF=“false”

#ETCD_METRICS=“basic”

#[Auth]

#ETCD_AUTH_TOKEN=“simple”

[root@etcd1 etcd]#

成员标志【member flags】

| 参数 | 使用说明 |

| — | — |

| --name 'default' | 本member的名字 |

| --data-dir '${name}.etcd' | 指定节点的数据存储目录，这些数据包括节点ID，集群ID，集群初始化配置，Snapshot文件，若未指定-wal-dir，还会存储WAL文件；如果不指定会用缺省目录。 |

| --listen-peer-urls http://0.0.0.0:2380 | 本member侧使用，用于监听其他member发送信息的地址。ip为全0代表监听本member侧所有接口 |

| --listen-client-urls http://0.0.0.0:2379 | 本member侧使用，用于监听etcd客户发送信息的地址。ip为全0代表监听本member侧所有接口 |

| --wal-dir 'path' | 到专用wal目录的路径 |

| --snapshot-count '100000' | 要将快照触发到磁盘的已提交事务数 |

| --heartbeat-interval '100' | 检测间隔的时间(毫秒) |

| --election-timeout '1000' | 超时时间(毫秒) |

| --initial-election-tick-advance 'true' | 是否提前初始化选举时钟启动，以便更快的选举 |

| --max-snapshots '5' | 要保留的最大快照文件数(0是无限的) |

| --max-wals '5' | 要保留的最大wal文件数(0是无限的) |

| --cors ' ' | omma单独的设置CORS来源白名单（跨来源资源共享） |

| --quota-backend-bytes '0' | 当后端大小超过给定限额时发出警报(0默认为低空间限额) |

| --max-txn-ops '128' | 事务中允许的最大操作数 |

| --max-request-bytes '1572864' | 服务器将接受的最大客户端请求大小(以字节为单位) |

| --grpc-keepalive-min-time '5s' | 客户端在ping服务器之前应该等待的最小持续时间间隔 |

| --grpc-keepalive-interval '2h' | 检查连接是否激活的服务器到客户机ping的频率持续时间(0表示禁用) |

| --grpc-keepalive-timeout '20s' | 关闭无响应连接之前的额外等待时间(0表示禁用) |

群集标志【clustering flags】

| 参数 | 使用说明 |

| — | — |

| --initial-advertise-peer-urls 'http://localhost:2380' | 其他member使用，其他member通过该地址与本member交互信息。一定要保证从其他member能可访问该地址。静态配置方式下，该参数的value一定要同时在–initial-cluster参数中存在。memberID的生成受–initial-cluster-token和–initial-advertise-peer-urls影响。 |

| --initial-cluster 'etcd01=http://localhost01:2380, etcd02=http://localhost02:2380, etcd03=http://localhost03:2380' | 本member侧使用。描述集群中所有节点的信息，本member根据此信息去联系其他member。memberID的生成受–initial-cluster-token和–initial-advertise-peer-urls影响。 |

| --initial-cluster-state 'new' | 用于指示本次是否为新建集群。有两个取值new和existing。如果填为existing，则该member启动时会尝试与其他member交互。集群初次建立时，要填为new，经尝试最后一个节点填existing也正常，其他节点不能填为existing。集群运行过程中，一个member故障后恢复时填为existing，经尝试填为new也正常。 |

| --initial-cluster-token 'etcd-cluster' | 引导期间etcd集群的初始集群令牌。在运行多个集群时，指定此参数可以防止意外的跨集群交互。 |

| --advertise-client-urls 'http://localhost:2379' | etcd客户使用，客户通过该地址与本member交互信息。一定要保证从客户侧能可访问该地址 |

| --discovery ' ' | 用于引导集群的发现URL，指定第三方etcd上key地址，要建立的集群各member都会向其注册自己的地址 |

| --enable-v2 'true' | 接受etcd V2客户端请求 |

| --discovery-fallback 'proxy' | 当发现服务失败时的预期行为(“exit”或“proxy”)。“proxy”只支持v2 API |

| --discovery-proxy ' ' | 用于传输到发现服务的HTTP代理 |

| --discovery-srv ' ' | 用于引导集群的dns srv域 |

| --strict-reconfig-check 'true' | 拒绝可能导致仲裁丢失的重新配置请求 |

| --auto-compaction-retention '0' | 自动压缩保留长度。0表示禁用自动压缩 |

| --auto-compaction-mode 'periodic' | 解释“自动压缩保留”之一：周期性丨“修订版”定期’用于基于持续时间的保留，如果没有提供时间单位，则默认为小时（例如’5m’）。’“版本号”用于基于版本号的保留。 |

代理标志【proxy flags】

注意：“proxy” supports v2 API only.

| 参数 | 使用说明 |

| — | — |

| --proxy 'off' | 代理模式设置（‘off’、‘readonly’或’on’） |

| --proxy-failure-wait 5000 | 终结点处于失败状态的时间（毫秒） |

| --proxy-refresh-interval 30000 | 端点刷新间隔的时间（毫秒） |

| --proxy-dial-timeout 1000 | 拨号超时的时间（毫秒） |

| --proxy-write-timeout 5000 | 写入超时的时间（毫秒） |
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。img

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注Java获取）

img

总结

面试难免让人焦虑不安。经历过的人都懂的。但是如果你提前预测面试官要问你的问题并想出得体的回答方式，就会容易很多。

此外，都说“面试造火箭，工作拧螺丝”，那对于准备面试的朋友，你只需懂一个字：刷！

给我刷刷刷刷，使劲儿刷刷刷刷刷！今天既是来谈面试的，那就必须得来整点面试真题，这不花了我整28天，做了份“Java一线大厂高岗面试题解析合集：JAVA基础-中级-高级面试+SSM框架+分布式+性能调优+微服务+并发编程+网络+设计模式+数据结构与算法等”

image

且除了单纯的刷题，也得需准备一本【JAVA进阶核心知识手册】：JVM、JAVA集合、JAVA多线程并发、JAVA基础、Spring 原理、微服务、Netty与RPC、网络、日志、Zookeeper、Kafka、RabbitMQ、Hbase、MongoDB、Cassandra、设计模式、负载均衡、数据库、一致性算法、JAVA算法、数据结构、加密算法、分布式缓存、Hadoop、Spark、Storm、YARN、机器学习、云计算，用来查漏补缺最好不过。

image

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！
.cn/images/e5c14a7895254671a72faed303032d36.jpg" alt=“img” style=“zoom: 33%;” />

总结

面试难免让人焦虑不安。经历过的人都懂的。但是如果你提前预测面试官要问你的问题并想出得体的回答方式，就会容易很多。

此外，都说“面试造火箭，工作拧螺丝”，那对于准备面试的朋友，你只需懂一个字：刷！

给我刷刷刷刷，使劲儿刷刷刷刷刷！今天既是来谈面试的，那就必须得来整点面试真题，这不花了我整28天，做了份“Java一线大厂高岗面试题解析合集：JAVA基础-中级-高级面试+SSM框架+分布式+性能调优+微服务+并发编程+网络+设计模式+数据结构与算法等”

[外链图片转存中…(img-KG3Z3nFm-1713211964054)]

且除了单纯的刷题，也得需准备一本【JAVA进阶核心知识手册】：JVM、JAVA集合、JAVA多线程并发、JAVA基础、Spring 原理、微服务、Netty与RPC、网络、日志、Zookeeper、Kafka、RabbitMQ、Hbase、MongoDB、Cassandra、设计模式、负载均衡、数据库、一致性算法、JAVA算法、数据结构、加密算法、分布式缓存、Hadoop、Spark、Storm、YARN、机器学习、云计算，用来查漏补缺最好不过。

[外链图片转存中…(img-I7HM3bFd-1713211964054)]

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！

# kubernetes # etcd # 容器
Logo
K8S/Kubernetes

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐

【深度】阿里巴巴万级规模 K8s 集群全局高可用体系之美

作者 |  韩堂、柘远、沉醉来源 | 阿里巴巴云原生公众号​前言台湾作家林清玄在接受记者采访的时候，如此评价自己 30 多年写作生涯：“第一个十年我才华横溢，‘贼光闪现’，令周边黯然失色；第二个十年，我终于‘宝光现形’，不再去抢风头，反而与身边的美丽相得益彰；进入第三个十年，繁华落尽见真醇，我进入了‘醇光初现’的阶段，真正体味到了境界之美”。​长夜有穷，真水无香。领略过了 K8s“身在江

avatar K8S/Kubernetes

如何基于 K8s 构建下一代 DevOps 平台？

作者 | 孙健波（天元）导读：当前云原生 DevOps 体系现状如何？面临哪些挑战？如何通过 OAM 解决云原生 DevOps 场景下的诸多问题？云原生开发应用模型 OAM(Open Application Model) 社区核心成员孙健波将为大家一一解答，并分享如何基于 OAM 和 Kubernetes 打造无限能力的下一代 DevOps 平台。什么是 DevOps？为什么基于 Kub

avatar K8S/Kubernetes

k8s 火了！

2020，上云之年，产品云端化成为一种趋势。在一线城市，很多公司都已经构建了自己的私有云环境，比如阿里云、网易云、华为云等。而Kubernetes 作为基于容器编排领域的王者，具备扩展...

avatar K8S/Kubernetes