分布式鎖用Redis還是Zookeeper

# 分布式鎖：用Redis還是Zookeeper？

## 目錄
1. [分布式鎖核心訴求](#一分布式鎖核心訴求)
   - 1.1 [互斥性](#11-互斥性)
   - 1.2 [可靠性](#12-可靠性)
   - 1.3 [可重入性](#13-可重入性)
   - 1.4 [死鎖預防](#14-死鎖預防)
2. [Redis實現方案](#二redis實現方案)
   - 2.1 [SETNX基礎實現](#21-setnx基礎實現)
   - 2.2 [RedLock算法](#22-redlock算法)
   - 2.3 [鎖續期機制](#23-鎖續期機制)
3. [Zookeeper實現方案](#三zookeeper實現方案)
   - 3.1 [臨時節點方案](#31-臨時節點方案)
   - 3.2 [順序節點優化](#32-順序節點優化)
   - 3.3 [Watch機制](#33-watch機制)
4. [關鍵對比維度](#四關鍵對比維度)
   - 4.1 [性能對比](#41-性能對比)
   - 4.2 [可靠性對比](#42-可靠性對比)
   - 4.3 [實現復雜度](#43-實現復雜度)
5. [典型場景選擇](#五典型場景選擇)
   - 5.1 [高并發短事務](#51-高并發短事務)
   - 5.2 [長事務強一致](#52-長事務強一致)
6. [生產實踐建議](#六生產實踐建議)
   - 6.1 [Redis配置要點](#61-redis配置要點)
   - 6.2 [Zookeeper調優](#62-zookeeper調優)
7. [未來發展趨勢](#七未來發展趨勢)

## 一、分布式鎖核心訴求

### 1.1 互斥性
在任何時刻，同一個鎖只能被一個客戶端持有。這是分布式鎖最基本的要求，需要通過原子性操作保證。

```java
// Redis偽代碼示例
Boolean lockAcquired = redis.set("lock_key", "value", "NX", "EX", 30);

1.2 可靠性

服務節點宕機時能自動釋放鎖，避免死鎖。Zookeeper通過臨時節點天然支持，Redis需要額外設計過期時間。

1.3 可重入性

同一個客戶端可多次獲取同一把鎖，需在客戶端維護持有計數（如圖示）：

┌─────────────┐       ┌─────────────┐
│  Client A   │       │  Lock       │
│  - holdCount:2      │  - Owner: A │
└─────────────┘       └─────────────┘

1.4 死鎖預防

需處理網絡分區、時鐘漂移等邊界情況。RedLock通過多實例投票機制解決，Zookeeper依賴會話超時。

二、Redis實現方案

2.1 SETNX基礎實現

def acquire_lock(conn, lockname, acquire_timeout=10):
    identifier = str(uuid.uuid4())
    end = time.time() + acquire_timeout
    while time.time() < end:
        if conn.setnx('lock:' + lockname, identifier):
            conn.expire('lock:' + lockname, lock_timeout)
            return identifier
        time.sleep(0.001)
    return False

缺陷分析：

1. 非原子性操作（setnx+expire）
2. 時鐘漂移問題
3. 單點故障風險

2.2 RedLock算法

算法步驟： 1. 獲取當前毫秒級時間戳 2. 依次向N個實例申請鎖 3. 當在(N/2+1)個實例上成功且總耗時小于鎖有效期時視為成功 4. 實際有效時間 = 初始有效時間 - 獲取鎖耗時

2.3 鎖續期機制

通過守護線程定期延長鎖有效期：

func (l *Lock) extendLock() {
    ticker := time.NewTicker(l.expiry / 3)
    for {
        select {
        case <-ticker.C:
            l.redisClient.Expire(l.key, l.expiry)
        case <-l.stopChan:
            return
        }
    }
}

三、Zookeeper實現方案

3.1 臨時節點方案

graph TD
    A[創建/lock臨時節點] --> B{創建成功?}
    B -->|是| C[獲取鎖]
    B -->|否| D[監聽節點刪除事件]
    D --> E[收到通知后重試]

3.2 順序節點優化

節點命名規則：

/lock-00000001
/lock-00000002
/lock-00000003

客戶端檢查自己是否是最小編號節點，否則監聽前序節點。

3.3 Watch機制

事件觸發流程： 1. 前序節點刪除觸發Watcher 2. 客戶端收到事件通知 3. 重新檢查節點順序 4. 獲取鎖或繼續等待

四、關鍵對比維度

4.1 性能對比

4.2 可靠性對比

Redis的潛在問題： - 主從切換導致鎖丟失 - 時鐘跳躍影響TTL

Zookeeper優勢： - Zab協議保證一致性 - 會話機制自動清理

五、典型場景選擇

5.1 高并發短事務

電商秒殺場景推薦Redis方案：

def seckill():
    lock = acquire_redis_lock("item_123")
    try:
        if stock > 0:
            reduce_stock()
    finally:
        release_lock(lock)

5.2 長事務強一致

金融交易系統建議Zookeeper：

public void transfer() {
    InterProcessMutex lock = new InterProcessMutex(client, "/account_lock");
    try {
        if (lock.acquire(30, TimeUnit.SECONDS)) {
            // 執行轉賬操作
        }
    } finally {
        lock.release();
    }
}

六、生產實踐建議

6.1 Redis配置要點

1. 建議5節點集群部署
2. 設置合理的down-after-milliseconds
3. 啟用持久化AOF+每秒fsync

6.2 Zookeeper調優

# zoo.cfg關鍵參數
tickTime=2000
initLimit=10
syncLimit=5
maxClientCnxns=60

七、未來發展趨勢

1. 混合方案興起（如Redis+Zookeeper雙校驗）
2. 基于Raft的新實現（如etcd）
3. 無鎖化設計（如CRDT數據結構）

最終決策樹： └─ 是否需要強一致？ ├─ 是 → 選擇Zookeeper └─ 否 → 選擇Redis “`

（注：此為精簡版框架，完整版需擴展每個章節的技術細節、性能測試數據、異常處理方案等內容至11000+字）