## 1. 為什麼選擇 Etcd

據官網介紹，Etcd 是一個分散式，可靠的 Key-Value 儲存系統，主要用於儲存分散式系統中的關鍵資料。初見之下，Etcd 與 NoSQL 資料庫系統有幾分相似，但作為資料庫絕非 Etcd 所長，其讀寫效能遠不如 MongoDB、Redis 等 Key-Value 儲存系統。“讓專業的人做專業的事！” Ectd 作為一個高可用的鍵值儲存系統，有很多典型的應用場景，本文將介紹 Etcd 的優秀實踐之一：分散式鎖。

### 1.1 Etcd 優點

目前，可實現分散式鎖的開源軟體有很多，其中應用最廣泛、大家最熟悉的應該就是 ZooKeeper，此外還有資料庫、Redis、Chubby 等。但若從讀寫效能、可靠性、可用性、安全性和複雜度等方面綜合考量，作為後起之秀的 Etcd 無疑是其中的 “佼佼者” 。它完全媲美業界“名宿”ZooKeeper，在有些方面，Etcd 甚至超越了 ZooKeeper，如 Etcd 採用的 Raft 協議就要比 ZooKeeper 採用的 Zab 協議簡單、易理解。

Etcd 作為 CoreOS 開源專案，有以下的特點。

- 簡單：使用 Go 語言編寫，部署簡單；支援 cURL 方式的使用者 API （HTTP+JSON），使用簡單；開源 Java 客戶端使用簡單；
 - 安全：可選 SSL 證照認證；
 - 快速：在保證強一致性的同時，讀寫效能優秀，詳情可檢視官方提供的 Benchmark 資料 ；
 - 可靠：採用 Raft 演算法實現分散式系統資料的高可用性和強一致性。

### 1.2 分散式鎖的基本原理

分散式環境下，多臺機器上多個程式對同一個共享資源（資料、檔案等）進行操作，如果不做互斥，就有可能出現“餘額扣成負數”，或者“商品超賣”的情況。為了解決這個問題，需要分散式鎖服務。首先，來看一下分散式鎖應該具備哪些條件。

- 互斥性：在任意時刻，對於同一個鎖，只有一個客戶端能持有，從而保證一個共享資源同一時間只能被一個客戶端操作；
 - 安全性：即不會形成死鎖，當一個客戶端在持有鎖的期間崩潰而沒有主動解鎖的情況下，其持有的鎖也能夠被正確釋放，並保證後續其它客戶端能加鎖；
 - 可用性：當提供鎖服務的節點發生當機等不可恢復性故障時，“熱備” 節點能夠接替故障的節點繼續提供服務，並保證自身持有的資料與故障節點一致。
 - 對稱性：對於任意一個鎖，其加鎖和解鎖必須是同一個客戶端，即客戶端 A 不能把客戶端 B 加的鎖給解了。

### 1.3 Etcd 實現分散式鎖的基礎

Etcd 的高可用性、強一致性不必多說，前面章節中已經闡明，本節主要介紹 Etcd 支援的以下機制：Watch 機制、Lease 機制、Revision 機制和 Prefix 機制，正是這些機制賦予了 Etcd 實現分散式鎖的能力。

- Lease 機制：即租約機制（TTL，Time To Live），Etcd 可以為儲存的 Key-Value 對設定租約，當租約到期，Key-Value 將失效刪除；同時也支援續約，透過客戶端可以在租約到期之前續約，以避免 Key-Value 對過期失效。Lease 機制可以保證分散式鎖的安全性，為鎖對應的 Key 配置租約，即使鎖的持有者因故障而不能主動釋放鎖，鎖也會因租約到期而自動釋放。
 - Revision 機制：每個 Key 帶有一個 Revision 號，每進行一次事務便加一，因此它是全域性唯一的，如初始值為 0，進行一次 put(key, value)，Key 的 Revision 變為 1，同樣的操作，再進行一次，Revision 變為 2；換成 key1 進行 put(key1, value) 操作，Revision 將變為 3；這種機制有一個作用：透過 Revision 的大小就可以知道寫操作的順序。在實現分散式鎖時，多個客戶端同時搶鎖，根據 Revision 號大小依次獲得鎖，可以避免 “羊群效應” （也稱“驚群效應”），實現公平鎖。
 - Prefix 機制：即字首機制，也稱目錄機制，例如，一個名為 /mylock 的鎖，兩個爭搶它的客戶端進行寫操作，實際寫入的 Key 分別為：key1="/mylock/UUID1",key2="/mylock/UUID2"，其中，UUID 表示全域性唯一的 ID，確保兩個 Key 的唯一性。很顯然，寫操作都會成功，但返回的 Revision 不一樣，那麼，如何判斷誰獲得了鎖呢？透過字首“/mylock” 查詢，返回包含兩個 Key-Value 對的 Key-Value 列表，同時也包含它們的 Revision，透過 Revision 大小，客戶端可以判斷自己是否獲得鎖，如果搶鎖失敗，則等待鎖釋放（對應的 Key 被刪除或者租約過期），然後再判斷自己是否可以獲得鎖。
 - Watch 機制：即監聽機制，Watch 機制支援監聽某個固定的 Key，也支援監聽一個範圍（字首機制），當被監聽的 Key 或範圍發生變化，客戶端將收到通知；在實現分散式鎖時，如果搶鎖失敗，可透過 Prefix 機制返回的 Key-Value 列表獲得 Revision 比自己小且相差最小的 Key（稱為 Pre-Key），對 Pre-Key 進行監聽，因為只有它釋放鎖，自己才能獲得鎖，如果監聽到 Pre-Key 的 DELETE 事件，則說明 Pre-Key 已經釋放，自己已經持有鎖。

## 2. Etcd 實現分散式鎖

### 2.1 基於 Etcd 的分散式鎖業務流程

下面描述了使用 Etcd 實現分散式鎖的業務流程，假設對某個共享資源設定的鎖名為：/anyrtc/mylock。

步驟1：準備
客戶端連線 Etcd，以 /anyrtc/mylock 為字首建立全域性唯一的 Key，假設第一個客戶端對應的 Key="/anyrtc/mylock/UUID1"，第二個為 Key="/anyrtc/mylock/UUID2"；客戶端分別為自己的 Key 建立租約 Lease，租約的長度根據業務耗時確定，假設為 15s。

步驟2：建立定時任務作為租約的“心跳”
在一個客戶端持有鎖期間，其它客戶端只能等待，為了避免等待期間租約失效，客戶端需建立一個定時任務作為“心跳”進行續約。此外，如果持有鎖期間客戶端崩潰，心跳停止，Key 將因租約到期而被刪除，從而鎖釋放，避免死鎖。

步驟3：客戶端將自己全域性唯一的 Key 寫入 Etcd
進行 Put 操作，將步驟 1 中建立的 Key 繫結租約寫入 Etcd，根據 Etcd 的 Revision 機制，假設兩個客戶端 Put 操作返回的 Revision 分別為1、2，客戶端需記錄 Revision 用以接下來判斷自己是否獲得鎖。

步驟4：客戶端判斷是否獲得鎖
客戶端以字首 /anyrtc/mylock 讀取 Key-Value 列表（Key-Value 中帶有 Key 對應的 Revision），判斷自己 Key 的 Revision 是否為當前列表中最小的，如果是則認為獲得鎖；否則監聽列表中前一個 Revision 比自己小的 Key 的刪除事件，一旦監聽到刪除事件或者因租約失效而刪除的事件，則自己獲得鎖。

步驟5：執行業務
獲得鎖後，操作共享資源，執行業務程式碼。

步驟6：釋放鎖
完成業務流程後，刪除對應的 Key 釋放鎖。

### 2.2 基於 Etcd 的分散式鎖的原理圖

根據上一節中介紹的業務流程，基於Etcd的分散式鎖示意圖如下。
![在這裡插入圖片描述](https://img-blog.csdnimg.cn/f411dc3e42f640e49906e284ed9abe89.png)

業務流程圖大家可參看這篇文章[《Zookeeper 分散式鎖實現原理》](https://blog.csdn.net/koflance/article/details/78616206)。

### 2.3 基於golang實現Etcd的分散式鎖

分散式鎖EtcdLocker程式碼

```
package etcd

import (
	"context"
	clientV3 "go.etcd.io/etcd/client/v3"
	"log"
	"os"
	"time"
)

// EtcdLocker 分散式鎖結構體
type EtcdLocker struct {
	client     *clientV3.Client // 連線到etcd的客戶端例項
	lease      clientV3.Lease   // 在etcd上的租約例項
	leaseId    clientV3.LeaseID
	cancelFunc context.CancelFunc
	option     Option
}

// Option EtcdClient的配置選項
type Option struct {
	ConnectionTimeout time.Duration // 連線到etcd的超時時間，示例：5*time.Second
	LeaseTtl          int64         // 租約時長，連線異常斷開後，未續租的租約會在這個時間之後失效
	Prefix            string        // 鎖字首
	Username          string        // 使用者名稱，可選
	Password          string        // 密碼，可選
	Debug             bool
}

// New 建立一把鎖
//  etcdEndpoints etcd連線資訊，示例：[]string{"localhost:2379"}
//  option 連線選項，包clientV3.Config中的配置項很多，我們其實用不到它們那麼多，簡化一下
func New(etcdEndpoints []string, option Option) (locker *EtcdLocker, err error) {
	if option.Prefix == "" {
		option.Prefix = "distribution_lock:"
	}
	if option.ConnectionTimeout <= 0 {
		option.ConnectionTimeout = 5 * time.Second
	}
	if option.LeaseTtl <= 0 {
		option.LeaseTtl = 5
	}
	config := clientV3.Config{
		Endpoints:   etcdEndpoints,
		DialTimeout: option.ConnectionTimeout,
		Username:    option.Username,
		Password:    option.Password,
	}
	locker = &EtcdLocker{
		option: option,
	}
	if locker.client, err = clientV3.New(config); err != nil {
		return nil, err
	}
	var timeoutCtx, cancel = context.Background(), locker.timeoutCancel
	timeoutCtx, cancel = context.WithTimeout(context.Background(), option.ConnectionTimeout)
	defer cancel()
	if _, err := locker.client.Status(timeoutCtx, etcdEndpoints[0]); err != nil {
		return nil, err
	}

//上鎖並建立租約
	locker.lease = clientV3.NewLease(locker.client)
	var leaseGrantResp *clientV3.LeaseGrantResponse
	// 第2個引數TTL，可以用於控制如果當前程式和etcd連線斷開了，持有鎖的上下文多長時間失效
	if leaseGrantResp, err = locker.lease.Grant(context.TODO(), option.LeaseTtl); err != nil {
		return nil, err
	}
	locker.leaseId = leaseGrantResp.ID
	var ctx context.Context
	// 建立一個可取消的租約，主要是為了退出的時候能夠釋放
	ctx, locker.cancelFunc = context.WithCancel(context.Background())
	var keepRespChan

技術分享| 基於 Etcd 的分散式鎖實現原理及方案

相關文章