網站首頁編程語言正文

Golang分布式鎖詳細介紹_Golang

作者：~龐貝 ? 更新時間： 2022-11-22 編程語言

進程內加鎖

想要得到正確的結果的話，把對 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)
// ... 省略之后部分

這樣就可以穩定地得到計算結果了：

??? go run local_lock.go
1000

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()
}

因為我們的邏輯限定每個 goroutine 只有成功執行了 Lock 才會繼續執行后續邏輯，因此在 Unlock 時可以保證 Lock struct 中的 channel 一定是空，從而不會阻塞，也不會失敗。

在單機系統中，trylock 并不是一個好選擇。因為大量的 goroutine 搶鎖可能會導致 cpu 無意義的資源浪費。有一個專有名詞用來描述這種搶鎖的場景：活鎖。

活鎖指的是程序看起來在正常執行，但實際上 cpu 周期被浪費在搶鎖，而非執行任務上，從而程序整體的執行效率低下。活鎖的問題定位起來要麻煩很多。所以在單機場景下，不建議使用這種鎖。

基于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 {
        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()
}

看看運行結果：

??? 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!

通過代碼和執行結果可以看到，我們遠程調用 setnx 實際上和單機的 trylock 非常相似，如果獲取鎖失敗，那么相關的任務邏輯就不應該繼續向前執行。

setnx 很適合在高并發場景下，用來爭搶一些“唯一”的資源。比如交易撮合系統中賣家發起訂單，而多個買家會對其進行并發爭搶。這種場景我們沒有辦法依賴具體的時間來判斷先后，因為不管是用戶設備的時間，還是分布式場景下的各臺機器的時間，都是沒有辦法在合并后保證正確的時序的。哪怕是我們同一個機房的集群，不同的機器的系統時間可能也會有細微的差別。

所以，我們需要依賴于這些請求到達 redis 節點的順序來做正確的搶鎖操作。如果用戶的網絡環境比較差，那也只能自求多福了。

基于zk

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")
}

基于 zk 的鎖與基于 redis 的鎖的不同之處在于 Lock 成功之前會一直阻塞，這與我們單機場景中的 mutex.Lock 很相似。

其原理也是基于臨時 sequence 節點和 watch api，例如我們這里使用的是 /lock 節點。Lock 會在該節點下的節點列表中插入自己的值，只要節點下的子節點發生變化，就會通知所有 watch 該節點的程序。這時候程序會檢查當前節點下最小的子節點的 id 是否與自己的一致。如果一致，說明加鎖成功了。

這種分布式的阻塞鎖比較適合分布式任務調度場景，但不適合高頻次持鎖時間短的搶鎖場景。按照 Google 的 chubby 論文里的闡述，基于強一致協議的鎖適用于 粗粒度 的加鎖操作。這里的粗粒度指鎖占用時間較長。我們在使用時也應思考在自己的業務場景中使用是否合適。

基于etcd

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 中沒有像 zookeeper 那樣的 sequence 節點。所以其鎖實現和基于 zookeeper 實現的有所不同。在上述示例代碼中使用的 etcdsync 的 Lock 流程是：

先檢查 /lock 路徑下是否有值，如果有值，說明鎖已經被別人搶了
如果沒有值，那么寫入自己的值。寫入成功返回，說明加鎖成功。寫入時如果節點被其它節點寫入過了，那么會導致加鎖失敗，這時候到 3
watch /lock 下的事件，此時陷入阻塞
當 /lock 路徑下發生事件時，當前進程被喚醒。檢查發生的事件是否是刪除事件(說明鎖被持有者主動 unlock)，或者過期事件(說明鎖過期失效)。如果是的話，那么回到 1，走搶鎖流程。

redlock

package main
import (
    "fmt"
    "time"
    "github.com/garyburd/redigo/redis"
    "gopkg.in/redsync.v1"
)
func newPool(server string) *redis.Pool {
    return &redis.Pool{
        MaxIdle:     3,
        IdleTimeout: 240 * time.Second,
        Dial: func() (redis.Conn, error) {
            c, err := redis.Dial("tcp", server)
            if err != nil {
                return nil, err
            }
            return c, err
        },
        TestOnBorrow: func(c redis.Conn, t time.Time) error {
            _, err := c.Do("PING")
            return err
        },
    }
}
func newPools(servers []string) []redsync.Pool {
    pools := []redsync.Pool{}
    for _, server := range servers {
        pool := newPool(server)
        pools = append(pools, pool)
    }
    return pools
}
func main() {
    pools := newPools([]string{"127.0.0.1:6379", "127.0.0.1:6378", "127.0.0.1:6377"})
    rs := redsync.New(pools)
    m := rs.NewMutex("/lock")
    err := m.Lock()
    if err != nil {
        panic(err)
    }
    fmt.Println("lock success")
    unlockRes := m.Unlock()
    fmt.Println("unlock result: ", unlockRes)
}

redlock 也是一種阻塞鎖，單個節點操作對應的是 set nx px 命令，超過半數節點返回成功時，就認為加鎖成功。

關于 redlock 的設計曾經在社區引起一場口水戰，分布式專家各抒己見。不過這個不是我們要討論的內容，相關鏈接在參考資料中給出。

如何選擇

業務還在單機就可以搞定的量級時，那么按照需求使用任意的單機鎖方案就可以。

如果發展到了分布式服務階段，但業務規模不大，比如 qps < 1000，使用哪種鎖方案都差不多。如果公司內已有可以使用的 zk/etcd/redis 集群，那么就盡量在不引入新的技術棧的情況下滿足業務需求。

業務發展到一定量級的話，就需要從多方面來考慮了。首先是你的鎖是否在任何惡劣的條件下都不允許數據丟失，如果不允許，那么就不要使用 redis 的 setnx 的簡單鎖。

如果要使用 redlock，那么要考慮你們公司 redis 的集群方案，是否可以直接把對應的 redis 的實例的 ip+port 暴露給開發人員。如果不可以，那也沒法用。

對鎖數據的可靠性要求極高的話，那只能使用 etcd 或者 zk 這種通過一致性協議保證數據可靠性的鎖方案。但可靠的背面往往都是較低的吞吐量和較高的延遲。需要根據業務的量級對其進行壓力測試，以確保分布式鎖所使用的 etcd/zk 集群可以承受得住實際的業務請求壓力。需要注意的是，etcd 和 zk 集群是沒有辦法通過增加節點來提高其性能的。要對其進行橫向擴展，只能增加搭建多個集群來支持更多的請求。這會進一步提高對運維和監控的要求。多個集群可能需要引入 proxy，沒有 proxy 那就需要業務去根據某個業務 id 來做 sharding。如果業務已經上線的情況下做擴展，還要考慮數據的動態遷移。這些都不是容易的事情。

在選擇具體的方案時，還是需要多加思考，對風險早做預估。

原文鏈接：https://blog.csdn.net/qq_53267860/article/details/127129404

上一篇：.NET中實現對象數據映射示例詳解_實用技巧
下一篇：GoLang?channel使用介紹_Golang

日本免费高清视频-国产福利视频导航-黄色在线播放国产-天天操天天操天天操天天操|www.shdianci.com

網站首頁編程語言正文

Golang分布式鎖詳細介紹_Golang

目錄

進程內加鎖

trylock

基于redis的setnx

基于zk

基于etcd

redlock

如何選擇

相關推薦

日本免费高清视频-国产福利视频导航-黄色在线播放国产-天天操天天操天天操天天操|www.shdianci.com

網站首頁 編程語言 正文

Golang分布式鎖詳細介紹_Golang

目錄

進程內加鎖

trylock

基于redis的setnx

基于zk

基于etcd

redlock

如何選擇

相關推薦

網站首頁編程語言正文