Golang分布式鎖詳細(xì)介紹
在單機(jī)程序并發(fā)或并行修改全局變量時(shí),需要對(duì)修改行為加鎖以創(chuàng)造臨界區(qū)。為什么需要加鎖呢?可以看看下段代碼:
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
進(jìn)程內(nèi)加鎖
想要得到正確的結(jié)果的話,把對(duì) 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
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 struct 中的 channel 一定是空,從而不會(huì)阻塞,也不會(huì)失敗。
在單機(jī)系統(tǒng)中,trylock 并不是一個(gè)好選擇。因?yàn)榇罅康?goroutine 搶鎖可能會(huì)導(dǎo)致 cpu 無意義的資源浪費(fèi)。有一個(gè)專有名詞用來描述這種搶鎖的場(chǎng)景:活鎖。
活鎖指的是程序看起來在正常執(zhí)行,但實(shí)際上 cpu 周期被浪費(fèi)在搶鎖,而非執(zhí)行任務(wù)上,從而程序整體的執(zhí)行效率低下?;铈i的問題定位起來要麻煩很多。所以在單機(jī)場(chǎng)景下,不建議使用這種鎖。
基于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()
}看看運(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!
通過代碼和執(zhí)行結(jié)果可以看到,我們遠(yuǎn)程調(diào)用 setnx 實(shí)際上和單機(jī)的 trylock 非常相似,如果獲取鎖失敗,那么相關(guān)的任務(wù)邏輯就不應(yīng)該繼續(xù)向前執(zhí)行。
setnx 很適合在高并發(fā)場(chǎng)景下,用來爭(zhēng)搶一些“唯一”的資源。比如交易撮合系統(tǒng)中賣家發(fā)起訂單,而多個(gè)買家會(huì)對(duì)其進(jìn)行并發(fā)爭(zhēng)搶。這種場(chǎng)景我們沒有辦法依賴具體的時(shí)間來判斷先后,因?yàn)椴还苁怯脩粼O(shè)備的時(shí)間,還是分布式場(chǎng)景下的各臺(tái)機(jī)器的時(shí)間,都是沒有辦法在合并后保證正確的時(shí)序的。哪怕是我們同一個(gè)機(jī)房的集群,不同的機(jī)器的系統(tǒng)時(shí)間可能也會(huì)有細(xì)微的差別。
所以,我們需要依賴于這些請(qǐng)求到達(dá) redis 節(jié)點(diǎn)的順序來做正確的搶鎖操作。如果用戶的網(wǎng)絡(luò)環(huán)境比較差,那也只能自求多福了。
基于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 成功之前會(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 是否與自己的一致。如果一致,說明加鎖成功了。
這種分布式的阻塞鎖比較適合分布式任務(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)景中使用是否合適。
基于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 節(jié)點(diǎn)。所以其鎖實(shí)現(xiàn)和基于 zookeeper 實(shí)現(xiàn)的有所不同。在上述示例代碼中使用的 etcdsync 的 Lock 流程是:
- 先檢查
/lock路徑下是否有值,如果有值,說明鎖已經(jīng)被別人搶了 - 如果沒有值,那么寫入自己的值。寫入成功返回,說明加鎖成功。寫入時(shí)如果節(jié)點(diǎn)被其它節(jié)點(diǎn)寫入過了,那么會(huì)導(dǎo)致加鎖失敗,這時(shí)候到 3
- watch
/lock下的事件,此時(shí)陷入阻塞 - 當(dāng)
/lock路徑下發(fā)生事件時(shí),當(dāng)前進(jìn)程被喚醒。檢查發(fā)生的事件是否是刪除事件(說明鎖被持有者主動(dòng) 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 也是一種阻塞鎖,單個(gè)節(jié)點(diǎn)操作對(duì)應(yīng)的是 set nx px 命令,超過半數(shù)節(jié)點(diǎn)返回成功時(shí),就認(rèn)為加鎖成功。
關(guān)于 redlock 的設(shè)計(jì)曾經(jīng)在社區(qū)引起一場(chǎng)口水戰(zhàn),分布式專家各抒己見。不過這個(gè)不是我們要討論的內(nèi)容,相關(guān)鏈接在參考資料中給出。
如何選擇
業(yè)務(wù)還在單機(jī)就可以搞定的量級(jí)時(shí),那么按照需求使用任意的單機(jī)鎖方案就可以。
如果發(fā)展到了分布式服務(wù)階段,但業(yè)務(wù)規(guī)模不大,比如 qps < 1000,使用哪種鎖方案都差不多。如果公司內(nèi)已有可以使用的 zk/etcd/redis 集群,那么就盡量在不引入新的技術(shù)棧的情況下滿足業(yè)務(wù)需求。
業(yè)務(wù)發(fā)展到一定量級(jí)的話,就需要從多方面來考慮了。首先是你的鎖是否在任何惡劣的條件下都不允許數(shù)據(jù)丟失,如果不允許,那么就不要使用 redis 的 setnx 的簡(jiǎn)單鎖。
如果要使用 redlock,那么要考慮你們公司 redis 的集群方案,是否可以直接把對(duì)應(yīng)的 redis 的實(shí)例的 ip+port 暴露給開發(fā)人員。如果不可以,那也沒法用。
對(duì)鎖數(shù)據(jù)的可靠性要求極高的話,那只能使用 etcd 或者 zk 這種通過一致性協(xié)議保證數(shù)據(jù)可靠性的鎖方案。但可靠的背面往往都是較低的吞吐量和較高的延遲。需要根據(jù)業(yè)務(wù)的量級(jí)對(duì)其進(jìn)行壓力測(cè)試,以確保分布式鎖所使用的 etcd/zk 集群可以承受得住實(shí)際的業(yè)務(wù)請(qǐng)求壓力。需要注意的是,etcd 和 zk 集群是沒有辦法通過增加節(jié)點(diǎn)來提高其性能的。要對(duì)其進(jìn)行橫向擴(kuò)展,只能增加搭建多個(gè)集群來支持更多的請(qǐng)求。這會(huì)進(jìn)一步提高對(duì)運(yùn)維和監(jiān)控的要求。多個(gè)集群可能需要引入 proxy,沒有 proxy 那就需要業(yè)務(wù)去根據(jù)某個(gè)業(yè)務(wù) id 來做 sharding。如果業(yè)務(wù)已經(jīng)上線的情況下做擴(kuò)展,還要考慮數(shù)據(jù)的動(dòng)態(tài)遷移。這些都不是容易的事情。
在選擇具體的方案時(shí),還是需要多加思考,對(duì)風(fēng)險(xiǎn)早做預(yù)估。
到此這篇關(guān)于Golang分布式鎖詳細(xì)介紹的文章就介紹到這了,更多相關(guān)Go分布式鎖內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
相關(guān)文章
Golang連接并操作PostgreSQL數(shù)據(jù)庫基本操作
PostgreSQL是常見的免費(fèi)的大型關(guān)系型數(shù)據(jù)庫,具有豐富的數(shù)據(jù)類型,也是軟件項(xiàng)目常用的數(shù)據(jù)庫之一,下面這篇文章主要給大家介紹了關(guān)于Golang連接并操作PostgreSQL數(shù)據(jù)庫基本操作的相關(guān)資料,需要的朋友可以參考下2022-09-09
go?install和go?get的區(qū)別實(shí)例詳解
go install是Golang用來編譯和安裝自定義package的工具,下面這篇文章主要給大家介紹了關(guān)于go?install和go?get區(qū)別的相關(guān)資料,文中通過實(shí)例代碼介紹的非常詳細(xì),需要的朋友可以參考下2023-01-01
Golang使用Gin框架實(shí)現(xiàn)HTTP上傳文件過程介紹
由于需求中有文件上傳這一個(gè)需求,在這里我們就學(xué)習(xí)一下go語言如何上傳文件。本文主要通過表單的方式進(jìn)行文件上傳操作,本文實(shí)例為大家分享了Go實(shí)現(xiàn)文件上傳操作的具體代碼,供大家參考,具體內(nèi)容如下2023-04-04
線上問題排查之golang使用json進(jìn)行對(duì)象copy
這篇文章主要介紹了線上問題排查之golang使用json進(jìn)行對(duì)象copy,文章圍繞golang使用json進(jìn)行對(duì)象copy的內(nèi)存溢出問題排查展開詳細(xì)內(nèi)容需要的小伙伴可以參考一下2022-06-06
一文搞懂Golang 時(shí)間和日期相關(guān)函數(shù)
這篇文章主要介紹了Golang 時(shí)間和日期相關(guān)函數(shù),本文通過實(shí)例代碼給大家介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或工作具有一定的參考借鑒價(jià)值,需要的朋友可以參考下2021-12-12
Golang正整數(shù)指定規(guī)則排序算法問題分析
這篇文章主要介紹了Golang正整數(shù)指定規(guī)則排序算法問題,結(jié)合實(shí)例形式分析了Go語言排序算法操作技巧,具有一定參考借鑒價(jià)值,需要的朋友可以參考下2017-01-01
總結(jié)Go語言中defer的使用和注意要點(diǎn)
Go語言中的defer關(guān)鍵字實(shí)現(xiàn)比較特殊的功能,這篇文章給大家總結(jié)了關(guān)于Go語言中defer的使用和注意要點(diǎn),有需要的朋友們可以參考借鑒,下面來一起看看吧。2016-09-09

