分布式锁：Redis / etcd / ZooKeeper 三种实现的全对比

Tue, 22 Feb 2022 11:00:00 +0800

2014 年 antirez 发表《Distributed locks with Redis》提出 Redlock；2016 年 Martin Kleppmann 在《How to do distributed locking》中公开反驳其正确性。这场争论留下的最重要结论是：分布式锁的正确性不能只靠锁本身。

理解分布式锁要先承认一个事实——没有完美的分布式锁。每种实现都有失效场景，工程师的任务是选一个"代价可接受"的方案，而不是找一个"绝对正确"的方案。

etcd Raft 一致性协议：从理论到工程实现

Mon, 15 Oct 2018 10:00:00 +0800

在分布式系统中，让多个节点对一组操作达成一致（Consensus）是难题。Diego Ongaro 在 2014 年的博士论文《Consensus: Bridging Theory and Practice》中提出 Raft 算法，专门为了可理解性而设计。相比 Paxos 的晦涩，Raft 用工程化的方式描述了 leader 选举、日志复制等机制。本文从原理到 etcd 的实现，逐步拆解 Raft。

为什么需要一致性协议

分布式 KV 存储（如 etcd、Consul）需要在多副本之间复制写操作：

单 leader 强一致性：写必须等大多数副本确认，延迟高但强一致
多 leader 最终一致性：写入本地即返回，后台异步复制，吞吐高但不保证顺序
无 leader：Dynamo 风格 quorum 读写

Raft 是单 leader 强一致性算法的代表，目标是让 3/5 个副本的集群能容忍 1/2 个节点故障。

Raft 三种角色

stateDiagram-v2
 [*] --> Follower

 Follower --> Candidate: 超时无心跳<br/>开始选举
 Candidate --> Leader: 获得多数票
 Candidate --> Follower: 发现更高 term
 Leader --> Follower: 发现更高 term

 Follower --> Follower: 收到合法心跳
 Leader --> Follower: 主动 step down

每个节点在任意时刻处于三种状态之一

etcd on Tony老师的博客

分布式锁：Redis / etcd / ZooKeeper 三种实现的全对比

etcd Raft 一致性协议：从理论到工程实现

为什么需要一致性协议

Raft 三种角色