Elasticsearch 是如何实现 Master 选举的？思维导图 代码示例（java 架构)

Elasticsearch 使用一个称为 Zen Discovery 的机制（在 7.x 版本之前）或基于协调节点的选举算法（从 7.x 开始，尤其是引入了“Voting-only nodes”之后）来实现 Master 节点选举。从 Elasticsearch 8.x 开始，默认使用的是 Quorum-based election algorithm，该算法旨在提高选举过程的可靠性和效率。

主要概念

1. Master Node:

   • 管理集群范围内的元数据变更，例如创建或删除索引、分配分片等。

2. Data Nodes:

   • 存储数据和执行与数据相关的操作，如搜索和聚合。

3. Client/Coordinator Nodes:

   • 不存储数据，只负责转发请求给正确的节点。

4. Voting-Only Nodes:

   • 只参与选举投票而不存储数据或处理搜索请求，用于增加选举的稳健性。

5. Quorum:

   • 在分布式系统中，quorum 是指为了做出决策而需要的最少成员数量。在 Elasticsearch 中，quorum 指的是参与投票的大多数 master-eligible 节点。

Master 选举流程

1. 初始化:

   • 集群启动时，所有有资格成为主节点的节点会尝试互相发现对方。

2. 选举提议:

   • 如果当前没有主节点，每个 master-eligible 节点都可以提议自己作为新的主节点。

3. 投票:

   • 所有的 voting-only 和 master-eligible 节点会对提议进行投票。

4. 达成共识:

   • 当超过半数（即 quorum）的投票节点同意某个提议时，该节点就被选为新的主节点。

5. 通知:

   • 新选出的主节点将更新其状态，并通知集群中的其他节点。

6. 故障转移:

   • 如果主节点失败，剩下的 master-eligible 节点将重新开始选举流程以选择一个新的主节点。

思维导图

对于思维导图，你可以构建如下结构：

• Elasticsearch 架构
  • Master Node
    • 管理元数据
    • 协调集群状态
  • Data Nodes
  • Client Nodes
  • Voting-Only Nodes
• Master 选举
  • 初始化
  • 提议
  • 投票
  • 达成共识
  • 通知
  • 故障转移

代码示例

由于 Elasticsearch 是用 Java 编写的，并且它的选举逻辑是内置于 Elasticsearch 内核中的，因此你不会直接在应用程序级别编写代码来控制这个过程。然而，你可以通过配置文件设置相关参数来影响选举行为。以下是一个简化版的 elasticsearch.yml 文件配置示例，它展示了如何配置 master-eligible 和 voting-only 节点：

# elasticsearch.yml

# 设置节点是否可以成为主节点
node.master: true

# 设置节点是否存储数据
node.data: false

# 设置节点是否是投票专用节点
node.voting_only: true

# 设置初始主节点列表
cluster.initial_master_nodes: ["node-1", "node-2", "node-3"]

# 设置最小投票节点数量（通常应为 master-eligible + voting-only 节点的一半加一）
discovery.zen.minimum_master_nodes: 2

请注意，以上配置适用于较早版本的 Elasticsearch（7.x 或更早）。对于最新的 Elasticsearch 版本（8.x），一些配置项可能已经更改或被移除。始终参考官方文档获取最准确的信息。

此外，如果你想要模拟或测试选举过程，你可以使用 Elasticsearch 的 REST API 或者 Java 客户端来管理集群状态，但这并不涉及实际的选举逻辑实现。选举逻辑是由 Elasticsearch 内部自动处理的，开发者不需要也通常无法直接干预这一过程。