复制 · 哨兵 · 集群 · 分布式锁

5.1主从复制

一主多副本：主库（master）处理写，副本（replica）异步接收写命令的字节流并重放；副本只读，主库宕机后副本的数据可能落后于主库最后一批已确认写。

全量同步

副本第一次连上主库（或因断线太久无法走增量），走全量同步（full resync）：

1. 副本发送 PSYNC ? -1，表示没有已知的复制偏移量。
2. 主库执行 BGSAVE（fork 一个子进程，利用 COW 生成 RDB 快照，见第 03 章），同时把这段时间到来的写命令写入复制积压缓冲区（replication backlog）。
3. RDB 文件通过 socket 传输到副本，副本清空本地数据并载入 RDB。
4. 载入完成后，主库把缓冲区里积累的写命令一次性发给副本，副本从此进入增量同步。

增量同步与复制积压缓冲区

主库为每条写命令分配一个复制偏移量（replication offset），并将命令字节流写入一个固定大小的环形缓冲区——复制积压缓冲区（默认 1MB，由 repl-backlog-size 控制）。副本断线重连后发送 PSYNC <runid> <offset>；若主库的 backlog 中还保有副本缺少的那段写，就直接补发这段差量（部分重同步，partial resync），避免重传整个 RDB。若断线期间写入量超过 backlog 容量，缺失部分已被覆盖，则退回全量同步。

5.2哨兵 Sentinel

哨兵（Sentinel）是一组独立进程，承担三件事：持续监控主/副本是否存活、在主库不可达时自动执行 failover、向客户端提供「当前主库地址」的服务发现接口。

主观下线与客观下线

单个哨兵每隔 1 秒向主库发 PING，若超过 down-after-milliseconds（默认 30000ms）没有有效响应，该哨兵单方面判定主库主观下线（Subjectively Down，SDOWN）。SDOWN 只是一个节点的看法，可能因网络抖动导致误判。

随后该哨兵向其他哨兵发送 SENTINEL is-master-down-by-addr 询问，收到足够多哨兵同意（票数 ≥ quorum 配置，通常为哨兵总数的多数派）后，判定主库客观下线（Objectively Down，ODOWN），触发 failover 流程。

选主与仲裁

进入 failover 的哨兵先通过 Raft-like 投票在哨兵集群中选出一个 Leader 哨兵（需 ≥ ⌊哨兵数/2⌋+1 票），由 Leader 独自完成选主逻辑。选副本的优先级顺序：① replica-priority 配置值小的优先；② 复制偏移量最大的（数据最新）优先；③ run ID 字典序最小的作为平局决胜。

选定新主后，Leader 哨兵向该副本发 REPLICAOF NO ONE，使其脱离副本角色；再把其他副本和客户端重定向到新主。客户端通过哨兵的 SENTINEL get-master-addr-by-name 拿到最新地址，或由客户端库（如 Jedis SentinelPool）自动在 failover 完成后重新连接。

5.3Cluster：16384 槽与 MOVED/ASK 重定向

Redis Cluster 把键空间划分为 16384 个 hash 槽（slot），每个节点负责其中一段连续槽范围；键通过 CRC16(key) % 16384 映射到槽，从而路由到对应节点。

为什么是 16384 个槽

槽的总数是 2¹⁴ = 16384，而非更常见的 2¹⁶ = 65536。原因在心跳包的大小：Cluster 节点之间定期交换包含槽位图（slot bitmap）的 gossip 心跳。16384 个槽需要 16384 bit = 2KB 的位图；65536 个槽则需要 8KB。集群节点数上限约 1000，16384 个槽对 1000 个节点已绰绰有余（每节点约 16 个槽），没必要为了扩展性付出 4× 的心跳带宽。

键到槽的映射：hash tag

槽号 = CRC16(key) % 16384。若 key 中包含花括号 {}，则只用花括号内的子串参与哈希——这叫 hash tag。例如 {user1}.name 和 {user1}.age 都只用 user1 计算槽号，因此落在同一个槽，允许对这两个 key 执行 MSET 或 Lua 操作而不触发 CROSSSLOT 错误。

MOVED 与 ASK：两种不同语义的重定向

客户端向某节点发送命令，该节点若判断 key 不属于自己，会回一个重定向错误。有两种：

区别的核心：MOVED 表示槽归属已定，客户端应更新本地的槽→节点映射缓存，之后对该槽的请求直接发新节点；ASK 表示这是迁移过程中的临时状态，客户端只为这一次请求做一次性重定向，不改变槽表，等迁移完成后收到 MOVED 再更新。

5.4分布式锁演进

分布式锁的核心诉求是：同一时刻最多一个客户端持有锁。Redis 的原子命令让它成为热门实现方案，但从 SETNX+EXPIRE 到 Redlock，每一步演进都在修补上一步留下的漏洞——且争议至今未定。

① SETNX + EXPIRE：两条命令的非原子漏洞

最朴素的实现：先 SETNX lock:resource 1（Set if Not eXists），成功后再 EXPIRE lock:resource 30。问题在于这是两条独立命令：若进程在 SETNX 成功后、EXPIRE 执行前崩溃，锁永远不会过期——死锁。这个窗口虽窄，但线上真实发生过。

② SET NX PX：原子获取

Redis 2.6.12 起支持扩展语法，把获取锁和设置过期合并为一条原子命令：

SET lock:resource <unique-uuid> NX PX 30000
# NX : 仅当 key 不存在时设置
# PX 30000 : 过期时间 30000 毫秒
# 返回 OK 表示获取成功，nil 表示已被持有

value 必须是唯一标识符（UUID 或进程+线程组合）。原因见下一步。

③ Lua 原子释放：compare-and-delete

释放锁时，不能直接 DEL lock:resource——若当前锁已被别人获取（自己的锁已过期），这一 DEL 会删掉别人的锁。正确做法是「先比对 value 是否是自己的，再删除」，这两步必须原子完成，否则比对通过后到删除前，锁恰好过期被他人获取，又回到问题。Lua 脚本是解法：

-- KEYS[1] = lock key, ARGV[1] = 当前持有者的 unique value
if redis.call("GET", KEYS[1]) == ARGV[1] then
    return redis.call("DEL", KEYS[1])
else
    return 0
end

GET 和 DEL 在 Lua 里整体提交，主线程一口气执行，中间不插入其他命令。value 比对确保只有持锁者能释放自己的锁。

④ Redlock：N 个独立 master 上的多数派锁

上述方案在单实例（含哨兵）上有一个根本漏洞：主库宕机、副本接管时，若刚才已确认的获锁写还没同步到副本，新主上不存在这把锁，另一个客户端可以再次获取——同一把锁被两个客户端同时持有。

Redlock 算法（antirez 提出）用 N 个相互独立的 Redis master（无主从关系，互不依赖）解这个问题：

1. 记下当前时间戳 t₀。
2. 依次向 N 个 master 发送 SET NX PX 获取请求（超时时间远小于锁的 TTL，避免因单节点慢而阻塞太久）。
3. 若在 ⌊N/2⌋+1 个以上节点获取成功，且耗费的总时间 Δt < 锁 TTL，则认为加锁成功；锁的有效剩余时间 = TTL − Δt。
4. 若未达到多数派，或 Δt 超出 TTL，则向所有节点发送释放命令，本次加锁失败。

即使其中 ⌊N/2⌋ 个节点宕机，剩余节点仍可构成多数派，锁依然可用。antirez 建议 N = 5。

⑤ Kleppmann 的批评：GC 停顿与时钟漂移

Martin Kleppmann（《数据密集型应用系统设计》作者）在 2016 年发表了How to do distributed locking，指出 Redlock 对「正确性」场景（即绝对不能两个客户端同时操作受保护资源）不安全，核心论证如下：

GC 停顿（Stop-the-World，STW）场景：客户端 1 获取锁，随即进入 JVM GC 的 STW 停顿。STW 期间锁过期，客户端 2 获取到同一把锁，开始操作资源。STW 结束，客户端 1 从停顿前的代码点恢复，它并不知道锁已过期，继续操作资源——两个客户端并发操作同一资源，互斥失效。

时钟漂移：Redlock 依赖各节点的系统时钟判断锁是否过期。若某节点时钟向前跳跃（NTP 调整、虚拟化环境的时钟漂移），锁会提前过期，导致同样的并发持锁问题。

Kleppmann 提出，唯一安全的解法是在资源端引入fencing token（围栏令牌，单调递增令牌）：锁服务每次授权时附带一个严格递增的令牌号，资源端记录已处理的最大令牌号，拒绝令牌号更小的请求——即使旧令牌持有者的请求后来才到达，也无法覆盖新令牌持有者的写入。Redis 无法生成这样的令牌，因此对「正确性」场景，他建议用 ZooKeeper（内建 zxid 单调递增）。

⑥ antirez 的回应

antirez 在Is Redlock safe?中回应：Redlock 面向效率（efficiency）而非绝对正确性（correctness），设计目标是「在多数节点正常时，减少并发进程同时操作的概率」，而非在所有故障模式下保证绝对互斥。他认为时钟漂移在实践中可以被工程手段约束到足够小；随机锁值（unique value）可以在资源端做一种弱形式的 fencing 校验。双方的分歧实质上是对「分布式锁应当提供效率保证还是正确性保证」的前提不同。

⑦ Redisson watchdog：解决持锁者提前过期

SET NX PX 30000 带来另一个问题：若持锁业务执行时间超过 30 秒，锁过期后别人可以获取，但原持锁者还在运行中——锁失效了，但业务不知道。

Redisson（Java Redis 客户端）的watchdog（看门狗）机制：调用 lock() 时不传 leaseTime（或传 -1），Redisson 在后台启动一个定时任务，每隔约 10 秒（lockWatchdogTimeout 的 1/3，默认 30s / 3）向 Redis 发一次续租命令，将锁的 TTL 重置回 lockWatchdogTimeout（默认 30000ms）。只要持锁进程存活，锁就不会提前过期。进程崩溃后 watchdog 停止续租，锁在 30 秒内自然过期，不会产生死锁。