原文鏈接：https://chai2010.cn/advanced-go-programming-book/ch6-cloud/ch6-02-lock.html

6.2 分布式鎖

在單機(jī)程序并發(fā)或并行修改全局變量時(shí)，需要對(duì)修改行為加鎖以創(chuàng)造臨界區(qū)。為什么需要加鎖呢？我們看看在不加鎖的情況下并發(fā)計(jì)數(shù)會(huì)發(fā)生什么情況：

package main

import (
    "sync"
)

// 全局變量
var counter int

func main() {
    var wg sync.WaitGroup
    for i := 0; i < 1000; i++ {
        wg.Add(1)
        go func() {
        defer wg.Done()
            counter++
        }()
    }

    wg.Wait()
    println(counter)
}

多次運(yùn)行會(huì)得到不同的結(jié)果：

??? go run local_lock.go
945
??? go run local_lock.go
937
??? go run local_lock.go
959

6.2.1 進(jìn)程內(nèi)加鎖

想要得到正確的結(jié)果的話，要把對(duì)計(jì)數(shù)器（counter）的操作代碼部分加上鎖：

// ... 省略之前部分
var wg sync.WaitGroup
var l sync.Mutex
for i := 0; i < 1000; i++ {
    wg.Add(1)
    go func() {
        defer wg.Done()
        l.Lock()
        counter++
        l.Unlock()
    }()
}

wg.Wait()
println(counter)
// ... 省略之后部分

這樣就可以穩(wěn)定地得到計(jì)算結(jié)果了：

??? go run local_lock.go
1000

6.2.2 trylock

在某些場(chǎng)景，我們只是希望一個(gè)任務(wù)有單一的執(zhí)行者。而不像計(jì)數(shù)器場(chǎng)景一樣，所有 goroutine 都執(zhí)行成功。后來(lái)的 goroutine 在搶鎖失敗后，需要放棄其流程。這時(shí)候就需要 trylock 了。

trylock 顧名思義，嘗試加鎖，加鎖成功執(zhí)行后續(xù)流程，如果加鎖失敗的話也不會(huì)阻塞，而會(huì)直接返回加鎖的結(jié)果。在 Go 語(yǔ)言中我們可以用大小為 1 的 Channel 來(lái)模擬 trylock：

package main

import (
    "sync"
)

// Lock try lock
type Lock struct {
    c chan struct{}
}

// NewLock generate a try lock
func NewLock() Lock {
    var l Lock
    l.c = make(chan struct{}, 1)
    l.c <- struct{}{}
    return l
}

// Lock try lock, return lock result
func (l Lock) Lock() bool {
    lockResult := false
    select {
    case <-l.c:
        lockResult = true
    default:
    }
    return lockResult
}

// Unlock , Unlock the try lock
func (l Lock) Unlock() {
    l.c <- struct{}{}
}

var counter int

func main() {
    var l = NewLock()
    var wg sync.WaitGroup
    for i := 0; i < 10; i++ {
        wg.Add(1)
        go func() {
            defer wg.Done()
            if !l.Lock() {
                // log error
                println("lock failed")
                return
            }
            counter++
            println("current counter", counter)
            l.Unlock()
        }()
    }
    wg.Wait()
}

因?yàn)槲覀兊倪壿嬒薅總€(gè) goroutine 只有成功執(zhí)行了 Lock 才會(huì)繼續(xù)執(zhí)行后續(xù)邏輯，因此在 Unlock 時(shí)可以保證 Lock 結(jié)構(gòu)體中的 channel 一定是空，從而不會(huì)阻塞，也不會(huì)失敗。上面的代碼使用了大小為 1 的 channel 來(lái)模擬 trylock，理論上還可以使用標(biāo)準(zhǔn)庫(kù)中的 CAS 來(lái)實(shí)現(xiàn)相同的功能且成本更低，讀者可以自行嘗試。

在單機(jī)系統(tǒng)中，trylock 并不是一個(gè)好選擇。因?yàn)榇罅康?goroutine 搶鎖可能會(huì)導(dǎo)致 CPU 無(wú)意義的資源浪費(fèi)。有一個(gè)專有名詞用來(lái)描述這種搶鎖的場(chǎng)景：活鎖。

活鎖指的是程序看起來(lái)在正常執(zhí)行，但 CPU 周期被浪費(fèi)在搶鎖，而非執(zhí)行任務(wù)上，從而程序整體的執(zhí)行效率低下?；铈i的問(wèn)題定位起來(lái)要麻煩很多。所以在單機(jī)場(chǎng)景下，不建議使用這種鎖。

6.2.3 基于 Redis 的 setnx

在分布式場(chǎng)景下，我們也需要這種 “搶占” 的邏輯，這時(shí)候怎么辦呢？我們可以使用 Redis 提供的 setnx 命令：

package main

import (
    "fmt"
    "sync"
    "time"

    "github.com/go-redis/redis"
)

func incr() {
    client := redis.NewClient(&redis.Options{
        Addr:     "localhost:6379",
        Password: "", // no password set
        DB:       0,  // use default DB
    })

    var lockKey = "counter_lock"
    var counterKey = "counter"

    // lock
    resp := client.SetNX(lockKey, 1, time.Second*5)
    lockSuccess, err := resp.Result()

    if err != nil || !lockSuccess {
        fmt.Println(err, "lock result:", lockSuccess)
        return
    }

    // counter ++
    getResp := client.Get(counterKey)
    cntValue, err := getResp.Int64()
    if err == nil || err == redis.Nil {
        cntValue++
        resp := client.Set(counterKey, cntValue, 0)
        _, err := resp.Result()
        if err != nil {
            // log err
            println("set value error!")
        }
    }
    println("current counter is", cntValue)

    delResp := client.Del(lockKey)
    unlockSuccess, err := delResp.Result()
    if err == nil && unlockSuccess > 0 {
        println("unlock success!")
    } else {
        println("unlock failed", err)
    }
}

func main() {
    var wg sync.WaitGroup
    for i := 0; i < 10; i++ {
        wg.Add(1)
        go func() {
            defer wg.Done()
            incr()
        }()
    }
    wg.Wait()
}

看看運(yùn)行結(jié)果：

??? go run redis_setnx.go
<nil> lock result:  false
<nil> lock result:  false
<nil> lock result:  false
<nil> lock result:  false
<nil> lock result:  false
<nil> lock result:  false
<nil> lock result:  false
<nil> lock result:  false
<nil> lock result:  false
current counter is  2028
unlock success!

通過(guò)代碼和執(zhí)行結(jié)果可以看到，我們遠(yuǎn)程調(diào)用 setnx 運(yùn)行流程上和單機(jī)的 trylock 非常相似，如果獲取鎖失敗，那么相關(guān)的任務(wù)邏輯就不應(yīng)該繼續(xù)向前執(zhí)行。

setnx 很適合在高并發(fā)場(chǎng)景下，用來(lái)爭(zhēng)搶一些 “唯一” 的資源。比如交易撮合系統(tǒng)中賣(mài)家發(fā)起訂單，而多個(gè)買(mǎi)家會(huì)對(duì)其進(jìn)行并發(fā)爭(zhēng)搶。這種場(chǎng)景我們沒(méi)有辦法依賴具體的時(shí)間來(lái)判斷先后，因?yàn)椴还苁怯脩粼O(shè)備的時(shí)間，還是分布式場(chǎng)景下的各臺(tái)機(jī)器的時(shí)間，都是沒(méi)有辦法在合并后保證正確的時(shí)序的。哪怕是我們同一個(gè)機(jī)房的集群，不同的機(jī)器的系統(tǒng)時(shí)間可能也會(huì)有細(xì)微的差別。

所以，我們需要依賴于這些請(qǐng)求到達(dá) Redis 節(jié)點(diǎn)的順序來(lái)做正確的搶鎖操作。如果用戶的網(wǎng)絡(luò)環(huán)境比較差，那也只能自求多福了。

6.2.4 基于 ZooKeeper

package main

import (
    "time"

    "github.com/samuel/go-zookeeper/zk"
)

func main() {
    c, _, err := zk.Connect([]string{"127.0.0.1"}, time.Second) //*10)
    if err != nil {
        panic(err)
    }
    l := zk.NewLock(c, "/lock", zk.WorldACL(zk.PermAll))
    err = l.Lock()
    if err != nil {
        panic(err)
    }
    println("lock succ, do your business logic")

    time.Sleep(time.Second * 10)

    // do some thing
    l.Unlock()
    println("unlock succ, finish business logic")
}

基于 ZooKeeper 的鎖與基于 Redis 的鎖的不同之處在于 Lock 成功之前會(huì)一直阻塞，這與我們單機(jī)場(chǎng)景中的 mutex.Lock 很相似。

其原理也是基于臨時(shí) Sequence 節(jié)點(diǎn)和 watch API，例如我們這里使用的是 /lock 節(jié)點(diǎn)。Lock 會(huì)在該節(jié)點(diǎn)下的節(jié)點(diǎn)列表中插入自己的值，只要節(jié)點(diǎn)下的子節(jié)點(diǎn)發(fā)生變化，就會(huì)通知所有 watch 該節(jié)點(diǎn)的程序。這時(shí)候程序會(huì)檢查當(dāng)前節(jié)點(diǎn)下最小的子節(jié)點(diǎn)的 id 是否與自己的一致。如果一致，說(shuō)明加鎖成功了。

這種分布式的阻塞鎖比較適合分布式任務(wù)調(diào)度場(chǎng)景，但不適合高頻次持鎖時(shí)間短的搶鎖場(chǎng)景。按照 Google 的 Chubby 論文里的闡述，基于強(qiáng)一致協(xié)議的鎖適用于 粗粒度 的加鎖操作。這里的粗粒度指鎖占用時(shí)間較長(zhǎng)。我們?cè)谑褂脮r(shí)也應(yīng)思考在自己的業(yè)務(wù)場(chǎng)景中使用是否合適。

6.2.5 基于 etcd

etcd 是分布式系統(tǒng)中，功能上與 ZooKeeper 類(lèi)似的組件，這兩年越來(lái)越火了。上面基于 ZooKeeper 我們實(shí)現(xiàn)了分布式阻塞鎖，基于 etcd，也可以實(shí)現(xiàn)類(lèi)似的功能：

package main

import (
    "log"

    "github.com/zieckey/etcdsync"
)

func main() {
    m, err := etcdsync.New("/lock", 10, []string{"http://127.0.0.1:2379"})
    if m == nil || err != nil {
        log.Printf("etcdsync.New failed")
        return
    }
    err = m.Lock()
    if err != nil {
        log.Printf("etcdsync.Lock failed")
        return
    }

    log.Printf("etcdsync.Lock OK")
    log.Printf("Get the lock. Do something here.")

    err = m.Unlock()
    if err != nil {
        log.Printf("etcdsync.Unlock failed")
    } else {
        log.Printf("etcdsync.Unlock OK")
    }
}

etcd 中沒(méi)有像 ZooKeeper 那樣的 Sequence 節(jié)點(diǎn)。所以其鎖實(shí)現(xiàn)和基于 ZooKeeper 實(shí)現(xiàn)的有所不同。在上述示例代碼中使用的 etcdsync 的 Lock 流程是：

1. 先檢查 ?/lock? 路徑下是否有值，如果有值，說(shuō)明鎖已經(jīng)被別人搶了
2. 如果沒(méi)有值，那么寫(xiě)入自己的值。寫(xiě)入成功返回，說(shuō)明加鎖成功。寫(xiě)入時(shí)如果節(jié)點(diǎn)被其它節(jié)點(diǎn)寫(xiě)入過(guò)了，那么會(huì)導(dǎo)致加鎖失敗，這時(shí)候到 3
3. watch ?/lock? 下的事件，此時(shí)陷入阻塞
4. 當(dāng) ?/lock? 路徑下發(fā)生事件時(shí)，當(dāng)前進(jìn)程被喚醒。檢查發(fā)生的事件是否是刪除事件（說(shuō)明鎖被持有者主動(dòng) unlock），或者過(guò)期事件（說(shuō)明鎖過(guò)期失效）。如果是的話，那么回到 1，走搶鎖流程。

值得一提的是，在 etcdv3 的 API 中官方已經(jīng)提供了可以直接使用的鎖 API，讀者可以查閱 etcd 的文檔做進(jìn)一步的學(xué)習(xí)。

6.2.7 如何選擇合適的鎖

業(yè)務(wù)還在單機(jī)就可以搞定的量級(jí)時(shí)，那么按照需求使用任意的單機(jī)鎖方案就可以。

如果發(fā)展到了分布式服務(wù)階段，但業(yè)務(wù)規(guī)模不大，qps 很小的情況下，使用哪種鎖方案都差不多。如果公司內(nèi)已有可以使用的 ZooKeeper、etcd 或者 Redis 集群，那么就盡量在不引入新的技術(shù)棧的情況下滿足業(yè)務(wù)需求。

業(yè)務(wù)發(fā)展到一定量級(jí)的話，就需要從多方面來(lái)考慮了。首先是你的鎖是否在任何惡劣的條件下都不允許數(shù)據(jù)丟失，如果不允許，那么就不要使用 Redis 的 setnx 的簡(jiǎn)單鎖。

對(duì)鎖數(shù)據(jù)的可靠性要求極高的話，那只能使用 etcd 或者 ZooKeeper 這種通過(guò)一致性協(xié)議保證數(shù)據(jù)可靠性的鎖方案。但可靠的背面往往都是較低的吞吐量和較高的延遲。需要根據(jù)業(yè)務(wù)的量級(jí)對(duì)其進(jìn)行壓力測(cè)試，以確保分布式鎖所使用的 etcd 或 ZooKeeper 集群可以承受得住實(shí)際的業(yè)務(wù)請(qǐng)求壓力。需要注意的是，etcd 和 Zookeeper 集群是沒(méi)有辦法通過(guò)增加節(jié)點(diǎn)來(lái)提高其性能的。要對(duì)其進(jìn)行橫向擴(kuò)展，只能增加搭建多個(gè)集群來(lái)支持更多的請(qǐng)求。這會(huì)進(jìn)一步提高對(duì)運(yùn)維和監(jiān)控的要求。多個(gè)集群可能需要引入 proxy，沒(méi)有 proxy 那就需要業(yè)務(wù)去根據(jù)某個(gè)業(yè)務(wù) id 來(lái)做分片。如果業(yè)務(wù)已經(jīng)上線的情況下做擴(kuò)展，還要考慮數(shù)據(jù)的動(dòng)態(tài)遷移。這些都不是容易的事情。

在選擇具體的方案時(shí)，還是需要多加思考，對(duì)風(fēng)險(xiǎn)早做預(yù)估。