浅谈分布式锁

本文探讨了在多线程环境下保证原子性的加锁机制,通过Go语言示例展示了单机自增计数器的问题及解决方案。接着介绍了在分布式场景下,如何利用Redis的setnx命令实现抢占式锁,并分析了其在高并发场景下的适用性。然后对比了基于Zookeeper和etcd的分布式锁实现,指出它们在锁获取上的差异以及适用场景。最后,提供了在不同量级业务场景下选择合适锁的建议,强调了数据可靠性和业务需求的重要性。
摘要由CSDN通过智能技术生成

为什么需要锁

单机程序,在多线程并发情况下,操作同一资源时,需要对其进行加锁等同步措施来保证原子性。举一个多线程自增的例子:

package main
import (
   "sync"
)
// 全局变量
var counter int
func main() {
   var wg sync.WaitGroup
   for i := 0; i < 100; i++ {
       wg.Add(1)
       go func() {
            counter++
            wg.Done()
       }()
   }
   wg.Wait()
   println(counter)
}

多次运行会得到不同的结果:

> go run test.go
98
> go run test.go
99
> go run test.go
100

显然这个结果不能让人满意,充满了不可预知。想要得到正确结果,就需要对计数自增加锁

package main

import (
    "sync"
)

// 全局变量
var counter int
var mtx sync.Mutex

func main() {
    var wg sync.WaitGroup
    for i := 0; i < 100; i++ {
        wg.Add(1)
        go func() {
            mtx.Lock()
            counter++
            mtx.Unlock()
            wg.Done()
        }()
    }
    wg.Wait()
    println(counter)
}

多次运行后得到的结果:

> go run test.go
100
> go run test.go
100
> go run test.go
100
一、基于Redis的setnx

在分布式场景下,我们也需要这种"抢占"的逻辑,这时候怎么办?我们可以使用Redis提供的setnx命令:

package main

import (
    "fmt"
    "strconv"
    "sync"
    "time"

    "gopkg.in/redis.v5"
)

var rds = redis.NewFailoverClient(&redis.FailoverOptions{
    MasterName:    "mymaster",
    SentinelAddrs: []string{"127.0.0.1:26379"},
})

// 全局变量
func incrby() error {

    lockkey := "count_key"
    counterkey := "counter"

    succ, err := rds.SetNX(lockkey, 1, time.Second*time.Duration(5)).Result()
    if err != nil || !succ {
        fmt.Println(err, " lock result:", succ)
        return err
    }

    defer func() {
        succ, err := rds.Del(lockkey).Result()
        if err == nil && succ > 0 {
            fmt.Println("unlock sucess")
        } else {
            fmt.Println("unlock failed, err=", err)
        }
    }()

    resp, err := rds.Get(counterkey).Result()
    if err != nil && err != redis.Nil {
        fmt.Println("get count failed, err=", err)
        return err
    }

    var cnt int64
    if err == nil {
        cnt, err = strconv.ParseInt(resp, 10, 64)
        if err != nil {
            fmt.Println("parse string failed, s=", resp)
            return err
        }
    }
    fmt.Println("curr cnt:", cnt)
    cnt++
    _, err = rds.Set(counterkey, cnt, 0).Result()
    if err != nil {
        fmt.Println("set value fialed,err=", err)
        return err
    }

    return nil
}

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

运行结果:

> go run test.go
curr cnt: 0
<nil>  lock result: false
unlock sucess
<nil>  lock result: false
curr cnt: 1
<nil>  lock result: false
unlock sucess
curr cnt: 2
<nil>  lock result: false
unlock sucess
curr cnt: 3
<nil>  lock result: false
<nil>  lock result: false
unlock sucess

远程调用setnx运行流程上和单机的trylock非常相似,如果获取锁失败,那么相关的任务逻辑就不会继续向下执行。
setnx很适合在高并发场景下,来争抢一些唯一的资源。

二、基于zookeeper
package main 
import (
    "fmt"
    "sync"
    "time"

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

var zkconn *zk.Conn
var count int64

func incrby() {
    lock := zk.NewLock(zkconn, "/lock", zk.WorldACL(zk.PermAll))
    err := lock.Lock()
    if err != nil {
        panic(err)
    }
    count++
    lock.Unlock()
}

func main() {
    c, _, err := zk.Connect([]string{"127.0.0.1"}, time.Second)
    if err != nil {
        fmt.Println("connect zookeeper failed, err=", err)
        return
    }
    zkconn = c
    var wg sync.WaitGroup
    for i := 0; i < 10; i++ {
        wg.Add(1)
        go func() {
            defer wg.Done()
            incrby()
        }()
    }
    wg.Wait()
    fmt.Println(" cnt :", count)
}

运行结果:

$ > go run test.go 
Connected to 127.0.0.1:2181
authenticated: id=72138376348368897, timeout=4000
re-submitting `0` credentials after reconnect
cnt : 10

基于ZooKeeper的锁与基于Redis锁不同之处在于lock成功之前会一直阻塞,这与sync.Mutex的Lock方法类似。
其原理是基于临时Sequence节点和watch API,例如我们这里使用的是/lock节点。Lock会在该节点下的节点列中插入自己的值,只要节点下的子节点发生变化,就会通知所有watch该节点的程序。这时候程序会检查当前节点下最小的子节点的id是否与自己的一致,一致则说明加锁成功了。
这种分布式的阻塞锁比较适合分布式任务调度场景,但不适合高频次持锁时间短的抢锁场景。按照Google的Chubby论文里的阐述,基于强一致协议的锁适用于 粗粒度的加锁操作。这里的粗粒度指锁占用时间较长。我们在使用时也应思考在自己的业务场景中使用是否合适

三、基于etcd

这个etcd的包"github.com/zieckey/etcdsync"拉取go mod会出现两次问题

#第一次
/etcd imports
        github.com/coreos/etcd/clientv3 tested by
        github.com/coreos/etcd/clientv3.test imports
        github.com/coreos/etcd/auth imports
        github.com/coreos/etcd/mvcc/backend imports
        github.com/coreos/bbolt: github.com/coreos/bbolt@v1.3.5: parsing go.mod:
        module declares its path as: go.etcd.io/bbolt
                but was required as: github.com/coreos/bbolt
#第二次
imports
        google.golang.org/grpc/naming: module google.golang.org/grpc@latest found (v1.32.0), but does not contain package google.golang.org/grpc/naming

需要在go.mod中加上

replace (
    github.com/coreos/bbolt v1.3.4 => go.etcd.io/bbolt v1.3.4
    go.etcd.io/bbolt v1.3.4 => github.com/coreos/bbolt v1.3.4
    google.golang.org/grpc => google.golang.org/grpc v1.26.0
)
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.Println("etcdsync.Lock failed, err=", err)
        return
    }
    log.Printf("etcdsync.Lock OK")
    log.Printf("Get the lock. Do something here.")
    err = m.Unlock()
    if err != nil {
        log.Println("etcdsync.Unlock failed, err=", err)
    } else {
        log.Printf("etcdsync.Unlock OK")
    }
}

etcd中没有像ZooKeeper那样的Sequence节点。所以其锁实现和基于ZooKeeper实现的有所不同。在上述示例代码中使用的etcdsync的Lock流程是:

  • 1、先检查/lock路径下是否有值,如果有值,说明锁已经被别人抢了
  • 2、如果没有值,那么写入自己的值。写入成功返回,说明加锁成功。写入时如果节点被其他节点写入过了,那么会导致加锁失败。
  • 3、watch /lock下的事件,此时陷入阻塞
  • 4、当/lock路径下发生事件时,当前进程被唤醒。检查发生的事件是否是删除事件(说明锁被持有者主动unlock),或者过期事件(锁过期失效),如果是的话,回到1,走抢锁流程。
如何选择合适的锁
单机量级

业务还在单机就可以搞定的量级下,那么按照需求使用任意的单机锁方案就可以。

分布式量级
  • 量级较低
    如果发展到分布式服务阶段,但业务规模不大,QPS很小的情况下,使用哪种锁的方案都差不多。如果公司内部有可以使用的ZooKeeper、etcd或者Redis集群,那么尽量不引入新的技术栈。
  • 量级较高
    如果锁是在任务恶劣的条件下都不允许数据丢失,那么就不能用Redis的setnx的简单锁。
    对锁数据的可靠性要求极高的话,那只能使用etcd或者ZooKeeper这种通过一致性协议保证数据可靠性的锁方案。(但可靠的背后往往都是较低的吞吐量和较高的延迟。需要根据业务的量级对其进行压力测试,以确保分布式锁所使用的的etcd和ZooKeeper集群可以承受得住实际的业务请求压力。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值