docs: 添加分布式协调机制和锁机制使用指南文档

- 新增《租约机制和其它分布式协调框架》文档，系统梳理分布式协调机制
- 新增《锁机制使用指南》文档，提供多语言锁机制实现示例
- 两篇文档共同构成后端分布式系统并发控制参考指南

Author: mudssky

docs/cheatsheet/backend/分布式/租约机制和其他分布式框架.md

@@ -0,0 +1,246 @@
+这个问题非常好！分布式场景下的协调机制远不止"分布式锁"一种。Lease（租约）确实是其中非常核心的一种，但它和"锁"既有联系又有本质区别。
+
+我们来系统性地梳理一下分布式场景中**所有主流的协调机制**。
+
+---
+
+## 一、 Lease（租约）机制
+
+### 它和分布式锁是什么关系？
+
+**Lease 是分布式锁的底层灵魂。** 准确地说：
+
+> **分布式锁 = Lease（租约）+ 资源绑定（锁名）+ 释放协议**
+
+一个纯粹的 Lease 只关心一件事：**"我在一段时间内拥有某种权利，到期自动作废"**。
+而分布式锁是 Lease 的一种具体应用：把这个"权利"绑定到了"独占某个资源"上。
+
+### Lease 的核心特征
+
+```
+┌──────────────────────────────────────────────┐
+│              Lease 租约模型                    │
+│                                              │
+│  持有者: Node-A                               │
+│  租约内容: "我有权处理 order-1001"              │
+│  有效期: 10秒 (TTL)                           │
+│  到期行为: 自动失效，无需手动释放               │
+│                                              │
+│  续约(Renew): 持有者可以在到期前主动续期        │
+│  撤销(Revoke): 中央协调者可以强制撤销           │
+└──────────────────────────────────────────────┘
+```
+
+### Lease vs Lock 的本质区别
+
+| 对比维度 | 传统分布式锁 | Lease 租约 |
+| :--- | :--- | :--- |
+| **生命周期** | 必须显式释放（`unlock()`） | **到期自动失效**，天然防死锁 |
+| **续期机制** | 可选（如 Redisson Watchdog） | **续约是核心设计**（心跳续约） |
+| **持有者崩溃** | 如果没设超时，可能永久死锁 | **自动过期释放**，其他节点可接管 |
+| **典型用途** | 保护临界区（如扣库存） | Leader 选举、服务注册、缓存一致性 |
+
+### Lease 在实际系统中的应用
+
+| 系统 | 怎么用 Lease 的 |
+| :--- | :--- |
+| **Kubernetes** | 每个 Pod 通过 Lease 对象向 API Server 上报心跳，**到期未续约则判定节点死亡**，触发 Pod 驱逐重调度 |
+| **Zookeeper** | 客户端与 ZK 建立 Session，本质就是一个 Lease。Session 过期 → 临时节点自动删除 → 触发 Watcher 通知 |
+| **etcd** | 通过 `Grant(TTL)` 创建租约，绑定到 Key 上。**Leader 选举的底层核心就是 Lease** |
+| **Redis** | `SET key value EX 10 NX` 本质就是一个 10 秒的 Lease |
+| **HDFS** | NameNode 给 DataNode 颁发 Lease，**持有 Lease 的客户端独占写文件权** |
+
+---
+
+## 二、 分布式场景中的其他常用协调机制
+
+除了"锁"和"租约"，分布式系统中还有一整套工具箱：
+
+---
+
+### 1. Leader Election（领导者选举）
+
+**解决的问题**：集群中多个节点，必须选出**唯一一个节点**来执行某项工作（比如定时任务调度、数据分片协调）。
+
+**底层原理**：通常就是基于 Lease 实现的！谁先抢到 Lease 谁就是 Leader，Leader 持续续约保持身份，一旦 Leader 崩溃、Lease 到期，其他节点重新竞选。
+
+```
+┌─────────────────────────────────────────────┐
+│          Leader Election 流程                │
+│                                             │
+│  Node-A ──► 尝试写入 /election/leader ──► 成功！成为 Leader
+│  Node-B ──► 尝试写入 /election/leader ──► 失败，Watch 等待
+│  Node-C ──► 尝试写入 /election/leader ──► 失败，Watch 等待
+│                                             │
+│  [Leader 崩溃] ──► Lease 到期 ──► Key 被删除  │
+│  Node-B ──► 抢到写入 ──► 成为新 Leader        │
+└─────────────────────────────────────────────┘
+```
+
+**实际应用**：
+
+| 系统 / 框架 | 怎么做 Leader 选举 |
+| :--- | :--- |
+| **Kubernetes** Controller Manager | 通过 **Lease 对象** 竞选，只有 Leader 实例工作 |
+| **Elasticsearch** | 通过内部共识协议选举 Master 节点 |
+| **Kafka** | Controller Broker 通过 Zookeeper 临时节点竞选 |
+| **自研业务** | 用 Redis `SETNX` 或 etcd `CreateRevision` 实现 |
+
+---
+
+### 2. Fencing Token（隔离令牌 / 防护令牌）
+
+**解决的问题**：分布式锁的一个致命漏洞 —— **锁过期了，但持有者还不知道**。
+
+```
+时间线:
+t1: Node-A 获取锁 (TTL=10s)
+t2: Node-A 发生 Full GC 停顿 30 秒...（它以为自己还持有锁）
+t3: 锁自动过期，Node-B 成功获取锁
+t4: Node-A 从 GC 中醒来，以为自己还有锁，继续写数据库 ← 💥 脑裂！
+```
+
+**Fencing Token 的解决方案**：
+每次获取锁时，锁服务会颁发一个**全局单调递增的令牌号（epoch / revision）**。
+下游资源（数据库、存储系统）会**拒绝接受过期令牌号的写入请求**。
+
+```
+Node-A 获取锁 → 得到 Token #35
+Node-B 获取锁 → 得到 Token #36
+Node-A 醒来，拿着 Token #35 去写数据库
+数据库: "我上次接受的是 #36，你的 #35 过时了，拒绝！"  ← ✅ 安全
+```
+
+**实际应用**：etcd 的 Revision、Zookeeper 的 zxid、Google Chubby 的 sequencer。
+
+---
+
+### 3. Idempotency（幂等性设计）
+
+**解决的问题**：网络超时后重试、消息队列重复投递、用户狂点按钮。**不是阻止并发，而是让重复执行也不会出错**。
+
+**核心思路**：每个操作携带一个**唯一的请求ID（幂等键）**，服务端记录已经处理过的 ID，重复请求直接返回上次的结果。
+
+```python
+# Python 伪代码
+def create_order(idempotency_key: str, data: dict):
+    # 第一步：检查这个 key 是否已经处理过
+    existing = redis.get(f"idem:{idempotency_key}")
+    if existing:
+        return json.loads(existing)  # 直接返回上次结果，不再执行
+
+    # 第二步：正常执行业务
+    result = do_create_order(data)
+
+    # 第三步：记录已处理，设置过期时间
+    redis.set(f"idem:{idempotency_key}", json.dumps(result), ex=3600)
+    return result
+```
+
+**实际应用**：
+
+- 支付接口（支付宝、Stripe）都要求传 `out_trade_no` 作为幂等键
+- 消息队列消费者的"去重表"
+- HTTP 的 `Idempotency-Key` Header 标准
+
+---
+
+### 4. Distributed Transaction（分布式事务）
+
+**解决的问题**：一个业务操作需要修改多个不同服务/数据库的数据，要保证**要么全成功，要么全回滚**。
+
+| 方案 | 核心思路 | 一致性 | 常用框架 |
+| :--- | :--- | :--- | :--- |
+| **2PC (两阶段提交)** | 协调者先问所有参与者"能不能提交？"，全部同意后再统一提交。 | 强一致 | MySQL XA、Seata AT模式 |
+| **TCC (Try-Confirm-Cancel)** | 业务层面拆成三步：预留资源 → 确认 → 取消。 | 强一致 | Seata TCC模式、Hmily |
+| **Saga (编排/协作)** | 把大事务拆成一系列小事务，每个小事务都有对应的**补偿回滚操作**。 | 最终一致 | Temporal、Cadence、自研 |
+| **本地消息表** | 业务操作和消息写入在同一个本地事务中，由后台任务异步投递消息。 | 最终一致 | 自研（非常实用） |
+
+```
+Saga 举例 (下单流程):
+ ┌────────────┐    ┌────────────┐    ┌────────────┐
+ │ 1.创建订单  │───►│ 2.扣减库存  │───►│ 3.扣减余额  │
+ │ 补偿:取消订单│◄───│ 补偿:恢复库存│◄───│ 补偿:退款   │  ← 任何一步失败，
+ └────────────┘    └────────────┘    └────────────┘    反向执行补偿操作
+```
+
+---
+
+### 5. CAS (Compare-And-Swap / 乐观并发控制)
+
+**解决的问题**：无锁并发！不加锁，而是在**更新的瞬间检查数据是否被别人改过**。
+
+这不仅仅用在数据库（乐观锁 `version`），在分布式协调系统中也是核心原语：
+
+| 系统 | CAS 的具体表现 |
+| :--- | :--- |
+| **etcd** | `Txn(If(key.Version == X).Then(Put(...)))` |
+| **Zookeeper** | `setData(path, data, expectedVersion)` |
+| **DynamoDB** | `ConditionExpression: "version = :v"` |
+| **Consul** | `PUT /kv/key?cas=<ModifyIndex>` |
+
+---
+
+### 6. Watch / Pub-Sub（事件通知）
+
+**解决的问题**：不轮询，而是**让状态变更主动通知到相关方**。常与 Lease、Leader 选举搭配使用。
+
+```
+典型用法:
+  Node-B watch "/election/leader"
+
+  [Leader Node-A 崩溃] 
+       → etcd 检测到 Lease 到期 
+       → 删除 Key 
+       → 通知所有 Watcher 
+       → Node-B 收到通知，立刻发起竞选
+```
+
+| 系统 | 通知机制 |
+| :--- | :--- |
+| **etcd** | `Watch` API（长连接流式推送） |
+| **Zookeeper** | `Watcher`（一次性触发，需重新注册） |
+| **Redis** | `Pub/Sub` 频道 或 `Keyspace Notification` |
+| **Consul** | Long Polling（`?index=X&wait=30s`） |
+
+---
+
+## 三、 全景总结
+
+```
+┌─────────────────────────────────────────────────────────────┐
+│               分布式协调机制全景图                              │
+│                                                             │
+│  ┌──────────┐                                               │
+│  │  Lease   │──── 最底层的原语，带 TTL 的临时"凭证"            │
+│  └────┬─────┘                                               │
+│       │ 基于 Lease 构建                                      │
+│       ├──► 分布式锁 (Lock)         ← 独占资源                │
+│       ├──► 领导者选举 (Election)    ← 独占角色                │
+│       └──► 服务注册/心跳 (Registry) ← 独占"我活着"的声明       │
+│                                                             │
+│  ┌──────────┐                                               │
+│  │   CAS    │──── 无锁乐观并发，"先不锁，改的时候再校验"        │
+│  └──────────┘                                               │
+│                                                             │
+│  ┌──────────┐                                               │
+│  │  Fencing │──── 防止锁过期后的脑裂，用单调递增 Token 隔离      │
+│  └──────────┘                                               │
+│                                                             │
+│  ┌──────────┐                                               │
+│  │ 幂等性    │──── 不阻止重复，而是让重复无害                    │
+│  └──────────┘                                               │
+│                                                             │
+│  ┌──────────┐                                               │
+│  │ 分布式事务 │──── 跨服务的"全成功或全回滚"                    │
+│  │ 2PC/Saga │                                               │
+│  └──────────┘                                               │
+│                                                             │
+│  ┌──────────┐                                               │
+│  │Watch/通知 │──── 状态变更的实时感知，驱动后续动作              │
+│  └──────────┘                                               │
+└─────────────────────────────────────────────────────────────┘
+```
+
+**一句话记忆**：
+> **Lease 是地基，Lock 和 Election 是房子，Fencing 是防盗门，CAS 是乐观派，幂等是佛系派，分布式事务是强迫症派，Watch 是通信兵。**