快捷導(dǎo)航

Go結(jié)合Redis用最簡單的方式實現(xiàn)分布式鎖

更新時間：2022年01月20日 15:36:15 作者：jiaxwu

本文主要介紹了Go結(jié)合Redis用最簡單的方式實現(xiàn)分布式鎖示例，文中通過示例代碼介紹的非常詳細(xì)，具有一定的參考價值，感興趣的小伙伴們可以參考一下

前言

在項目中我們經(jīng)常有需要使用分布式鎖的場景，而Redis是實現(xiàn)分布式鎖最常見的一種方式，并且我們也都希望能夠把代碼寫得簡單一點(diǎn)，所以今天我們盡量用最簡單的方式來實現(xiàn)。

下面的代碼使用go-redis客戶端和gofakeit，參考和引用了Redis官方文章

單Redis實例場景

如果熟悉Redis的命令，可能會馬上想到使用Redis的set if not exists操作來實現(xiàn)，并且現(xiàn)在標(biāo)準(zhǔn)的實現(xiàn)方式是SET resource_name my_random_value NX PX 30000這串命令，其中：

resource_name表示要鎖定的資源
NX表示如果不存在則設(shè)置
PX 30000表示過期時間為30000毫秒，也就是30秒
my_random_value這個值在所有的客戶端必須是唯一的，所有同一key的獲取者（競爭者）這個值都不能一樣。

value的值必須是隨機(jī)數(shù)主要是為了更安全的釋放鎖，釋放鎖的時候使用腳本告訴Redis:只有key存在并且存儲的值和我指定的值一樣才能告訴我刪除成功?？梢酝ㄟ^以下Lua腳本實現(xiàn)：

if redis.call("get",KEYS[1]) == ARGV[1] then
? ? return redis.call("del",KEYS[1])
else
? ? return 0
end

舉個例子：客戶端A取得資源鎖，但是緊接著被一個其他操作阻塞了，當(dāng)客戶端A運(yùn)行完畢其他操作后要釋放鎖時，原來的鎖早已超時并且被Redis自動釋放，并且在這期間資源鎖又被客戶端B再次獲取到。

使用Lua腳本是因為判斷和刪除是兩個操作，所以有可能A剛判斷完鎖就過期自動釋放了，然后B就獲取到了鎖，然后A又調(diào)用了Del，導(dǎo)致把B的鎖給釋放了。

加解鎖示例

package main

import (
? ?"context"
? ?"errors"
? ?"fmt"
? ?"github.com/brianvoe/gofakeit/v6"
? ?"github.com/go-redis/redis/v8"
? ?"sync"
? ?"time"
)

var client *redis.Client

const unlockScript = `
if redis.call("get",KEYS[1]) == ARGV[1] then
? ? return redis.call("del",KEYS[1])
else
? ? return 0
end`

func lottery(ctx context.Context) error {
? ?// 加鎖
? ?myRandomValue := gofakeit.UUID()
? ?resourceName := "resource_name"
? ?ok, err := client.SetNX(ctx, resourceName, myRandomValue, time.Second*30).Result()
? ?if err != nil {
? ? ? return err
? ?}
? ?if !ok {
? ? ? return errors.New("系統(tǒng)繁忙，請重試")
? ?}
? ?// 解鎖
? ?defer func() {
? ? ? script := redis.NewScript(unlockScript)
? ? ? script.Run(ctx, client, []string{resourceName}, myRandomValue)
? ?}()

? ?// 業(yè)務(wù)處理
? ?time.Sleep(time.Second)
? ?return nil
}

func main() {
? ?client = redis.NewClient(&redis.Options{
? ? ? Addr: "127.0.0.1:6379",
? ?})
? ?var wg sync.WaitGroup
? ?wg.Add(2)
? ?go func() {
? ? ? defer wg.Done()
? ? ? ctx, _ := context.WithTimeout(context.Background(), time.Second*3)
? ? ? err := lottery(ctx)
? ? ? if err != nil {
? ? ? ? ?fmt.Println(err)
? ? ? }
? ?}()
? ?go func() {
? ? ? defer wg.Done()
? ? ? ctx, _ := context.WithTimeout(context.Background(), time.Second*3)
? ? ? err := lottery(ctx)
? ? ? if err != nil {
? ? ? ? ?fmt.Println(err)
? ? ? }
? ?}()
? ?wg.Wait()
}

我們先看lottery()函數(shù)，這里模擬一個抽獎操作，在進(jìn)入函數(shù)時，先使用SET resource_name my_random_value NX PX 30000加鎖，這里使用UUID作為隨機(jī)值，如果操作失敗，直接返回，讓用戶重試，如果成功在defer里面執(zhí)行解鎖邏輯，解鎖邏輯就是執(zhí)行前面說到得lua腳本，然后再進(jìn)行業(yè)務(wù)處理。

我們在main()函數(shù)里面執(zhí)行了兩個goroutine并發(fā)調(diào)用lottery()函數(shù)，其中有一個操作會因為拿不到鎖而直接失敗。

小結(jié)

生成隨機(jī)值
使用SET resource_name my_random_value NX PX 30000加鎖
如果加鎖失敗，直接返回
defer添加解鎖邏輯，保證在函數(shù)退出的時候會執(zhí)行
執(zhí)行業(yè)務(wù)邏輯

多Redis實例場景

在單實例情況下，如果這個實例掛了，那么所有請求都會因為拿不到鎖而失敗，所以我們需要多個分布在不同機(jī)器上的Redis實例，并且拿到其中大多數(shù)節(jié)點(diǎn)的鎖才能加鎖成功，這也就是RedLock算法。它其實也是基于上面的單實例算法的，只是我們需要同時對多個Redis實例獲取鎖。

加解鎖示例

package main

import (
? ?"context"
? ?"errors"
? ?"fmt"
? ?"github.com/brianvoe/gofakeit/v6"
? ?"github.com/go-redis/redis/v8"
? ?"sync"
? ?"time"
)

var clients []*redis.Client

const unlockScript = `
if redis.call("get",KEYS[1]) == ARGV[1] then
? ? return redis.call("del",KEYS[1])
else
? ? return 0
end`

func lottery(ctx context.Context) error {
? ?// 加鎖
? ?myRandomValue := gofakeit.UUID()
? ?resourceName := "resource_name"
? ?var wg sync.WaitGroup
? ?wg.Add(len(clients))
? ?// 這里主要是確保不要加鎖太久，這樣會導(dǎo)致業(yè)務(wù)處理的時間變少
? ?lockCtx, _ := context.WithTimeout(ctx, time.Millisecond*5)
? ?// 成功獲得鎖的Redis實例的客戶端
? ?successClients := make(chan *redis.Client, len(clients))
? ?for _, client := range clients {
? ? ? go func(client *redis.Client) {
? ? ? ? ?defer wg.Done()
? ? ? ? ?ok, err := client.SetNX(lockCtx, resourceName, myRandomValue, time.Second*30).Result()
? ? ? ? ?if err != nil {
? ? ? ? ? ? return
? ? ? ? ?}
? ? ? ? ?if !ok {
? ? ? ? ? ? return
? ? ? ? ?}
? ? ? ? ?successClients <- client
? ? ? }(client)
? ?}
? ?wg.Wait() // 等待所有獲取鎖操作完成
? ?close(successClients)
? ?// 解鎖，不管加鎖是否成功，最后都要把已經(jīng)獲得的鎖給釋放掉
? ?defer func() {
? ? ? script := redis.NewScript(unlockScript)
? ? ? for client := range successClients {
? ? ? ? ?go func(client *redis.Client) {
? ? ? ? ? ? script.Run(ctx, client, []string{resourceName}, myRandomValue)
? ? ? ? ?}(client)
? ? ? }
? ?}()
? ?// 如果成功加鎖得客戶端少于客戶端數(shù)量的一半+1，表示加鎖失敗
? ?if len(successClients) < len(clients)/2+1 {
? ? ? return errors.New("系統(tǒng)繁忙，請重試")
? ?}

? ?// 業(yè)務(wù)處理
? ?time.Sleep(time.Second)
? ?return nil
}

func main() {
? ?clients = append(clients, redis.NewClient(&redis.Options{
? ? ? Addr: "127.0.0.1:6379",
? ? ? DB: ? 0,
? ?}), redis.NewClient(&redis.Options{
? ? ? Addr: "127.0.0.1:6379",
? ? ? DB: ? 1,
? ?}), redis.NewClient(&redis.Options{
? ? ? Addr: "127.0.0.1:6379",
? ? ? DB: ? 2,
? ?}), redis.NewClient(&redis.Options{
? ? ? Addr: "127.0.0.1:6379",
? ? ? DB: ? 3,
? ?}), redis.NewClient(&redis.Options{
? ? ? Addr: "127.0.0.1:6379",
? ? ? DB: ? 4,
? ?}))
? ?var wg sync.WaitGroup
? ?wg.Add(2)
? ?go func() {
? ? ? defer wg.Done()
? ? ? ctx, _ := context.WithTimeout(context.Background(), time.Second*3)
? ? ? err := lottery(ctx)
? ? ? if err != nil {
? ? ? ? ?fmt.Println(err)
? ? ? }
? ?}()
? ?go func() {
? ? ? defer wg.Done()
? ? ? ctx, _ := context.WithTimeout(context.Background(), time.Second*3)
? ? ? err := lottery(ctx)
? ? ? if err != nil {
? ? ? ? ?fmt.Println(err)
? ? ? }
? ?}()
? ?wg.Wait()
? ?time.Sleep(time.Second)?
}

在上面的代碼中，我們使用Redis的多數(shù)據(jù)庫模擬多個Redis master實例，一般我們會選擇5個Redis實例，真實環(huán)境中這些實例應(yīng)該是分布在不同機(jī)器上的，避免同時失效。
在加鎖邏輯里，我們主要是對每個Redis實例執(zhí)行SET resource_name my_random_value NX PX 30000獲取鎖，然后把成功獲取鎖的客戶端放到一個channel里（這里使用slice可能有并發(fā)問題），同時使用sync.WaitGroup等待所以獲取鎖操作結(jié)束。
然后添加defer釋放鎖邏輯，釋放鎖邏輯很簡單，只是把成功拿到的鎖給釋放掉即可。
最后判斷成功獲取到的鎖的數(shù)量是否大于一半，如果沒有得到一半以上的鎖，說明加鎖失敗。
如果加鎖成功接下來就是進(jìn)行業(yè)務(wù)處理。

小結(jié)

生成隨機(jī)值
并發(fā)給每個Redis實例使用SET resource_name my_random_value NX PX 30000加鎖
等待所有獲取鎖操作完成
defer添加解鎖邏輯，保證在函數(shù)退出的時候會執(zhí)行，這里先defer再判斷是因為有可能獲取到一部分Redis實例的鎖，但是因為沒有超過一半，還是會判斷為加鎖失敗
判斷是否拿到一半以上Redis實例的鎖，如果沒有說明加鎖失敗，直接返回
執(zhí)行業(yè)務(wù)邏輯