7. 分布式协调原语实战

在分布式系统中，我们经常需要协调多个节点的行为，比如确保同一时间只有一个节点能执行某个任务（分布式锁），或者在主节点故障时快速选举出新的主节点（领导选举）。etcd 作为优秀的分布式键值存储，不仅提供了强一致性的数据存储，还内置了一套强大的分布式协调原语。这些原语并非简单的客户端封装，而是基于 etcd 核心的 Lease（租约）机制和 Watch（监听）机制构建的，能够提供高性能、高可靠性的分布式协调服务。

本章将深入探讨 etcd 的分布式协调能力。我们将从最基础的 Lease API 开始，逐步讲解如何利用它实现分布式锁、领导选举以及服务发现等经典模式。理解这些内容，能帮助我们更好地设计和构建高可用的分布式应用。

Lease API 与 TTL 管理

在分布式协调中，一个核心问题是：如何判断一个节点是否还“活着”？如果一个节点挂了，它持有的锁或选举的领导地位应该在何时失效？直接依赖节点的心跳检测往往不够鲁棒，因为网络延迟或节点负载都可能导致误判。

etcd 提供了 Lease（租约）机制来优雅地解决这个问题。Lease 本质上是一个具有生存时间（TTL）的令牌。客户端可以向 etcd 申请一个 Lease，并定期发送心跳来续租。如果 etcd 在一段时间内没有收到心跳，就会自动过期并撤销这个 Lease。

所有绑定到该 Lease 的键（Key）都会在 Lease 过期时被自动删除。这为分布式状态管理提供了一个非常强大的“超时释放”机制。

Lease 的核心操作

根据 API 参考文档，Lease 服务主要包含以下几个方法：

LeaseGrant: 创建一个新的租约，指定 TTL（生存时间）。
LeaseRevoke: 主动撤销一个租约，立即删除所有绑定的键。
LeaseKeepAlive: 保持租约活跃的双向流。客户端通过这个流持续发送心跳。
LeaseTimeToLive: 查询指定租约的详细信息，包括剩余 TTL 和绑定的键列表。
LeaseLeases: 列出当前集群中所有的租约。

实践：使用 etcdctl 管理租约

让我们通过 etcdctl 命令行工具来体验一下 Lease 的生命周期。

1. 创建一个租约

假设我们想创建一个 TTL 为 10 秒的租约：

# --ttl 指定生存时间，返回的 ID 是租约的唯一标识
etcdctl lease grant 10

执行后，你会看到类似这样的输出：

lease 694d7b42617ca30a granted with TTL(10s)

这里的 694d7b42617ca30a 就是租约 ID。

2. 将键绑定到租约

创建一个键 /lock/mylock，并将其与上面的租约关联起来。当租约过期时，这个键会自动被删除。

# --lease 指定租约 ID
etcdctl put /lock/mylock "value" --lease=694d7b42617ca30a

现在，你可以查询这个键：

etcdctl get /lock/mylock

它会正常返回值。等待 10 秒后，再次查询，你会发现键已经不存在了，因为租约过期导致它被自动删除了。

3. 续租（Keepalive）

如果我们希望在任务完成前一直持有这个租约，就需要定期续租。etcdctl 提供了一个方便的命令来持续续租：

# 这个命令会阻塞，并持续发送心跳
etcdctl lease keep-alive 694d7b42617ca30a

只要这个命令在运行，租约就不会过期。你可以按 Ctrl+C 停止续租，等待 TTL 到期后，键就会消失。

4. 查看租约信息

你可以随时查看租约的剩余时间和绑定的键：

etcdctl lease timetolive 694d7b42617ca30a --with-keys

输出会显示剩余的 TTL 和该租约关联的所有键。

5. 撤销租约

如果你想主动释放资源，可以直接撤销租约，这会立即删除所有绑定的键：

etcdctl lease revoke 694d7b42617ca30a

Lease 机制是 etcd 分布式协调能力的基石。它将“存活状态”与“网络连接”解耦，提供了一种基于时间的、自动化的资源清理机制。接下来我们要讲的分布式锁和领导选举，都深度依赖于 Lease。

分布式锁实现

在分布式系统中，我们经常需要保证某个资源或代码段在同一时间只能被一个节点访问。这就是分布式锁的作用。etcd 提供了现成的分布式锁服务，其内部实现正是基于 Lease 和版本号（Revision）机制。

根据 API 文档，Lock 服务提供了两个核心方法：

Lock: 获取一个命名的分布式锁。
Unlock: 释放一个之前获取的锁。

锁的工作原理

当一个客户端调用 Lock 方法时，etcd 内部会执行以下逻辑：

创建锁标识：etcd 会在一个预定义的前缀下创建一个代表“锁请求”的键。这个键的值包含了客户端信息，并且它与一个 Lease 绑定。这个 Lease 的 TTL 决定了如果客户端崩溃，锁能被挂持多久。
竞争与等待：如果这个命名的锁已经被其他客户端持有，新的请求会进入等待状态。它会通过 Watch 机制监听那个代表“当前持有者”的键的变化。
获取锁：当锁被释放（持有者主动 Unlock 或其 Lease 过期）时，等待队列中的第一个请求者会收到通知。etcd 会将锁的所有权转移给这个请求者，通常是通过更新一个代表“当前持有者”的主键来完成。
持有锁：成功获取锁的客户端会得到一个唯一的键（key），这个键是它持有锁的凭证。在调用 Unlock 时需要提供这个键。

实践：使用 etcdctl 获取和释放锁

etcdctl 封装了这些复杂的逻辑，让我们可以轻松地使用锁。

1. 获取锁

假设我们有两个客户端都想获取名为 my_mutex 的锁。

客户端 1：

# 这个命令会阻塞，直到成功获取锁
etcdctl lock my_mutex

执行后，客户端 1 会成功获取锁，并输出一个唯一的 key，例如 my_mutex/694d7b42617ca30a。此时，这个终端会一直阻塞，代表锁被持有。

客户端 2：

在另一个终端中，客户端 2 尝试获取同一个锁：

etcdctl lock my_mutex

你会发现这个命令没有任何输出，并且一直处于阻塞状态，因为它在等待客户端 1 释放锁。

2. 释放锁

回到客户端 1 的终端，按 Ctrl+C 终止 etcdctl lock 命令。这会触发 Unlock 操作。

此时，客户端 2 的终端会立即获得输出，显示它成功获取了锁，并输出一个新的 key。

锁的高级用法与注意事项

API 文档中的 LockRequest 提到了一个 lease 字段。这意味着客户端可以指定一个已有的 Lease 来关联锁。这样做有两个好处：

自动释放：如果持有锁的客户端崩溃，无法继续续租，那么 Lease 会过期，锁会自动释放，避免了死锁。
会话复用：一个客户端可以使用同一个 Lease 来获取多个锁，这些锁的生命周期与客户端的“会话”绑定。

重要提示：etcd 的锁服务是“公平锁”，它会按照请求的顺序依次分配锁，避免了“惊群效应”。但正如 why.md 文件中提到的，分布式锁的正确使用远比想象中复杂。仅仅获取到锁是不够的，你还需要结合业务逻辑和版本号（Revision）检查来确保操作的原子性，这被称为“ fencing token ”或“隔离墙”机制。例如，在写入数据时，你应该使用事务（Transaction）来检查你持有的锁的版本号是否仍然是最新的，以防止在你持有锁期间，由于时钟漂移或网络问题导致旧的锁状态被误用。

领导选举机制

领导选举是分布式系统中另一个常见的协调模式。它用于在一组对等节点中选出一个“主节点”（Leader），由主节点来协调任务、处理请求或管理状态。当主节点故障时，系统能自动重新选举出新的主节点，保证服务的连续性。

etcd 通过 Election 服务提供了领导选举的能力。与锁服务类似，它也是基于 Lease 和 Watch 机制构建的。

根据 API 文档，Election 服务包含以下方法：

Campaign: 发起一次选举，尝试成为领导者。
Proclaim: 领导者更新其发表的值（Value）。
Leader: 查询当前的领导者信息。
Observe: 观察领导者的变化，持续接收领导者变更的通知。
Resign: 当前领导者主动放弃领导地位，触发新一轮选举。

领导选举的工作流程

发起竞选：一个节点调用 Campaign 方法，指定一个选举名称（Name）和自己的提案（Value）。这个调用会阻塞，直到该节点成为领导者。
成为领导者：etcd 会检查该选举名称下是否存在有效的领导者。如果没有，当前节点就成为领导者。etcd 会创建一个代表领导者的键，并将其与节点提供的 Lease 绑定。节点会得到一个 LeaderKey，用于后续操作。
维持领导：成为领导者后，节点需要持续为 Lease 续租，以保持其领导地位。
其他节点：其他调用 Campaign 的节点会发现已有领导者，于是它们会 Watch 代表领导者的键，等待领导者下台（Lease 过期或主动 Resign）。
领导者变更：当领导者下台时，等待中的节点中会有一个（通常是第一个）成为新的领导者。

实践：使用 etcdctl 进行领导选举

etcdctl 同样提供了 elect 命令来模拟这个过程。

1. 节点 1 发起竞选

# elect <选举名称> <提案内容>
etcdctl elect my_election "node1"

节点 1 会成功当选，并阻塞在这里，代表它正在担任领导者。

2. 节点 2 尝试竞选

在另一个终端，节点 2 发起同样的竞选：

etcdctl elect my_election "node2"

这个命令会阻塞，因为节点 1 还是领导者。

3. 节点 1 退出

在节点 1 的终端按 Ctrl+C。这会触发 Resign 操作，节点 1 放弃领导权。

此时，节点 2 的终端会立即获得输出，显示它成为了新的领导者，并输出提案内容 "node2"。

领导选举在很多场景下比锁更适用。例如，在主从架构的数据库中，我们需要一个主节点来处理写请求。使用锁的话，主节点必须持续持有锁，一旦锁释放（比如因为网络抖动），系统就会陷入混乱。而使用领导选举，主节点通过续租来维持地位，即使短暂失联，只要 Lease 未过期，它仍然可以认为自己是合法的领导者，这大大提高了系统的稳定性。

服务发现模式

服务发现是微服务架构中的核心组件。它允许服务实例动态地注册自己，并让消费者能够发现它们。etcd 的键值模型和 Lease 机制非常适合实现服务发现。

一个典型的服务发现模式包含以下步骤：

服务注册：服务实例启动时，在 etcd 中创建一个键，例如 /services/my-service/instance-1，并将自己的地址、端口等信息作为值。这个键必须与一个 Lease 绑定。
健康检查与心跳：服务实例需要定期为 Lease 续租，以证明自己还活着。如果实例崩溃或网络中断，Lease 会过期，etcd 会自动删除该键。
服务发现：消费者（客户端）通过 Get 或 Watch 前缀 /services/my-service/ 来获取所有健康的服务实例列表。
服务下线：当服务实例正常关闭时，它应该主动撤销 Lease，从而立即从服务列表中移除自己。

实践：模拟服务发现

我们可以用 etcdctl 来模拟这个过程。

1. 服务注册

实例 1：创建一个租约，并注册服务。

# 步骤1: 创建租约
etcdctl lease grant 30
# 假设得到的 ID 是 694d7b42617ca30b

# 步骤2: 注册服务，并绑定租约
etcdctl put /services/my-service/instance-1 "192.168.1.10:8080" --lease=694d7b42617ca30b

实例 2：同样注册。

# 创建另一个租约
etcdctl lease grant 30
# 假设 ID 是 694d7b42617ca30c

# 注册
etcdctl put /services/my-service/instance-2 "192.168.1.11:8080" --lease=694d7b42617ca30c

2. 服务发现

消费者可以通过前缀查询来获取所有实例：

etcdctl get /services/my-service/ --prefix

输出会显示两个实例的信息。

3. 模拟实例故障

我们不给实例 1 续租，等待 30 秒后，再次查询：

etcdctl get /services/my-service/ --prefix

你会发现只剩下实例 2 的信息了，因为实例 1 的租约过期，其注册信息被自动清理。

4. 使用 Watch 实现实时发现

在实际应用中，消费者通常使用 Watch 来实时监听服务列表的变化，而不是轮询。

etcdctl watch /services/my-service/ --prefix

现在，如果你在另一个终端删除实例 2 的服务：

# 先获取实例 2 的租约 ID，然后撤销它
etcdctl lease revoke 694d7b42617ca30c

watch 命令的终端会立即收到一个删除事件，通知消费者实例 2 已下线。同样，如果新启动一个实例，watch 也会收到新增事件。

这种基于 Lease 和 Watch 的服务发现模式，既高效又可靠，是构建弹性分布式系统的基石。

Keepalive 机制

在前面的章节中，我们反复提到了“续租”这个动作。在 etcd 中，这个动作被称为 Keepalive。它是维持 Lease 生命线的核心机制。

LeaseKeepAlive 是一个 gRPC 双向流（Bidirectional Stream）。客户端通过这个流不断地向服务端发送心跳请求，服务端收到后会回复一个响应，确认 Lease 已经续期。

为什么使用双向流？

使用双向流而不是简单的 RPC 调用有以下好处：

连接复用：一个长连接可以为多个 Lease 发送心跳，减少了频繁建立 TCP 连接的开销。
低延迟：流式通信减少了请求头的重复发送，使得心跳更轻量、更快速。
实时反馈：客户端能立即知道自己的心跳是否成功，如果 Lease 已经被撤销，服务端会立即返回错误，客户端可以马上做出反应（例如，尝试重新获取锁或重新注册服务）。

客户端如何实现 Keepalive？

虽然 etcdctl 封装了 lease keep-alive 的细节，但在实际的客户端编程中（例如使用 Go 客户端库），你需要手动管理这个流。

一个典型的 Go 客户端实现 Keepalive 的逻辑如下：

// 伪代码，展示核心逻辑
import "go.etcd.io/etcd/client/v3"

// 1. 创建 Lease
resp, err := client.Grant(ctx, 10)
if err != nil { /* ... */ }
leaseID := resp.ID

// 2. 创建 KeepAlive 通道
keepAliveChan, err := client.KeepAlive(ctx, leaseID)
if err != nil { /* ... */ }

// 3. 启动一个 goroutine 来消费 KeepAlive 响应
go func() {
    for {
        select {
        case _, ok := <-keepAliveChan:
            if !ok {
                // 通道关闭，可能 Lease 已被撤销或客户端连接断开
                // 需要处理重连或重新获取 Lease 的逻辑
                return
            }
            // 收到心跳响应，说明 Lease 还活着
            // 可以在这里记录日志或做其他处理
        case <-ctx.Done():
            return
        }
    }
}()

// 4. 在业务逻辑中，当需要撤销 Lease 时
// client.Revoke(ctx, leaseID)

Keepalive 的注意事项

TTL 与心跳间隔：客户端库通常会自动处理心跳间隔，一般会在 TTL 的基础上留出一些余量，比如 TTL 为 10 秒，心跳可能每 5-7 秒发送一次。开发者无需手动控制频率。
连接断开：如果客户端与 etcd 集群的网络中断，KeepAlive 流会断开。客户端库通常会尝试自动重连并重新建立 KeepAlive 流。但在重连成功之前，Lease 会因为收不到心跳而过期。因此，应用需要准备好 Lease 失效后的应对策略。
资源清理：当应用退出时，应该调用 Revoke 来主动撤销 Lease，这比等待 Lease 自然过期要好，可以更快地释放资源。

本章小结

本章我们深入探索了 etcd 的分布式协调原语，这些是构建复杂分布式应用的强力工具。

我们从 Lease API 开始，它是所有协调能力的基石。Lease 提供了一种基于 TTL 的自动过期机制，完美解决了分布式环境下的节点存活判断问题。

基于 Lease，我们学习了 分布式锁。它通过 Lock 和 Unlock 服务，为共享资源提供了互斥访问能力。我们通过 etcdctl lock 演示了其基本用法，并强调了结合事务来保证操作正确性的重要性。

接着，我们探讨了 领导选举。相比锁，领导选举更适合于主从架构的场景，它通过 Campaign 和 Resign 等方法，提供了一个更稳定、更符合业务语义的领导者管理机制。

然后，我们展示了如何利用 Lease 和 Watch 实现 服务发现。这是一种动态管理服务实例列表的经典模式，具有自动清理故障节点的优点。

最后，我们详细讲解了 Keepalive 机制。它是维持 Lease 生命线的通信协议，通过高效的双向流，确保客户端与服务端之间的心跳能够稳定、低延迟地进行。

掌握这些协调原语，意味着我们不仅能使用 etcd 存储数据，更能利用它来协调分布式系统中各个组件的行为，从而构建出更加健壮和自动化的系统。在下一章，我们将把视线转向 etcd 的集群管理，看看如何部署和运维一个高可用的 etcd 集群。

Etcd 速读教程

7.分布式协调原语实战