1. 分布式锁
叶落山城秋: 本文是我摘自其他网站,觉得不错,文章最后有原文链接
1.1. 不加锁
在单机程序并发或并行修改全局变量时,需要对修改行为加锁以创造临界区,为什么需要加锁呢?我们看看在不加锁的情况下并发技术会发生什么情况:
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)
}
多次运行会得到不同的结果:
[18:47:06] xzghua:interview git:(master*) $ go run test.go
944
[18:47:09] xzghua:interview git:(master*) $ go run test.go
933
[18:47:10] xzghua:interview git:(master*) $ go run test.go
924
[18:47:11] xzghua:interview git:(master*) $ go run test.go
945
[18:47:12] xzghua:interview git:(master*) $ go run test.go
952
叶落山城秋: 此处对go协程不太了解的解释一下,协程简单理解为并行运行,正常代码运行是 从上往下,上面运行结束了 继续往下走, 但是并行就不一定了,两个同时运行,但是谁先运行完不一定,比如上面例子,你for循环 i已经从1都加到2了,可能协程里还没开始或者还在运行中,不过也可能 运行结束了都不一定, 上面的go协程肯定也是会运行1000遍的,但是值为什么不是1000呢,因为可能出现两次或者多次协程读取的counter是同一个值,比如这个协程 读取的counter值是99,那个读取的也是99,最后++后,counter值都是100,但是已经运行多遍了.. 如果想要得到1000,可以 加上
runtime.GOMAXPROCS(1)单核运行 单核运行会进行排序..
1.2. 进程内加锁
想要得到正确的结果的话,要把计数器(counter)的操作代码部分加上锁:
package main
import (
"sync"
)
// 全局变量
var counter int
func main() {
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)
}
这样就可以稳定地得到计算结果了：
[18:57:12] xzghua:interview git:(master*) $ go run test.go
1000
叶落山城秋: 主进程for会一直执行,但是go协程因为只有一把锁,每次运行需要获取锁释放锁才能继续执行,限制了执行顺序,必须得乖乖执行
1.3. trylock
在某些场景,我们只是希望一个任务有单一的执行者,而不像计数器场景一样,所有的goroutine都执行成功的,后来的goroutine在抢锁失败后,需要放弃其流程,这时候就需要trylock了
trylock顾名思义,尝试加锁,加锁成功后执行后续流程,如果加锁失败的话不会阻塞,而会直接返回加锁的结果,在Go语言中我们可以用大小为1的Channel来模拟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结构体中的channel一定是空,从而不会阻塞,也不会失败
上面的代码使用了大小为1的channel来模拟trylock,理论上还可以使用标准库中的CAS来实现相同的功能且成本更低,大家可自行尝试
在单机系统中,trylock并不是一个好选择,因为大量的goroutine抢锁可能会导致CPU无意义的浪费资源,有一个专有名词用来描述这种抢锁的场景:活锁
活锁指的是程序看起来在正常执行,但CPU周期被浪费在抢锁,而非执行任务上,从而程序整体的执行效率底下,活锁的问题定位起来要麻烦很多,所以在单机场景下,不建议使用这种锁
1.4. 基于Redis的setnx
这个得记住,要考,平常可以考虑用
在分布式场景下,我们也需要这种"抢占"的逻辑,这时候怎么办呢,我们可以使用Redis提供的setnx命令:
func RedisLock() {
var wg sync.WaitGroup
for i:=0;i<100;i++ {
wg.Add(1)
go func() {
defer wg.Done()
incr()
}()
}
wg.Wait()
}
func incr() {
client := redis.NewClient(&redis.Options{
Network: "",
Addr: "localhost:6379",
Password: "",
DB: 0,
})
var lockKey = "counter_lock"
var counterKey = "counter"
// lock
// 设置一个 锁标记,redis的string类型,SetNx 只有在键Key不存在的时候,将键Key的值设置成value,如果存在,SetNx不做任何操作
// 此处方便理解,我把过期时间设置为 用不过期
resp := client.SetNX(lockKey,1,0)
lockSuccess,err := resp.Result()
// 如果设置不成功,说明已经有人锁住了..本协程直接返回
if err != nil || !lockSuccess {
fmt.Println(err, "lock result: ", lockSuccess)
return
}
// counter++
// 正常加了锁的进程获取 记录的key,然后进行++操作
// 然后再放回redis里存着
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 {
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)
}
}
执行的结果是:
[16:27:36] xzghua:interview git:(master*) $ go run test.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 1
unlock success!
通过代码和执行结果可以看到，我们远程调用setnx运行流程上和单机的trylock非常相似，如果获取锁失败，那么相关的任务逻辑就不应该继续向前执行。
setnx很适合在高并发场景下，用来争抢一些“唯一”的资源。比如交易撮合系统中卖家发起订单，而多个买家会对其进行并发争抢。 这种场景我们没有办法依赖具体的时间来判断先后，因为不管是用户设备的时间，还是分布式场景下的各台机器的时间，都是没有办法在合并后保证正确的时序的。 哪怕是我们同一个机房的集群，不同的机器的系统时间可能也会有细微的差别。
所以，我们需要依赖于这些请求到达Redis节点的顺序来做正确的抢锁操作。如果用户的网络环境比较差，那也只能自求多福了。
叶落山城秋: 这种方法的实质是 在redis里利用SetNx存一个key对应value,第一个人先抢到设置了,并且没有释放,那么它就可以操作其他流程了,而其他的人 再来抢的时候,发现已经被人设置了,而且还没有释放,那么他就没有资格继续操作了,就直接返回了..一直等到拿到锁的人释放了,下一个获取到,下一个人才能继续执行...
1.5. 基于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成功之前会一直阻塞，这与我们单机场景中的mutex.Lock很相似。
其原理也是基于临时Sequence节点和watch API，例如我们这里使用的是/lock节点。Lock会在该节点下的节点列表中插入自己的值，只要节点下的子节点发生变化，就会通知所有watch该节点的程序。这时候程序会检查当前节点下最小的子节点的id是否与自己的一致。如果一致，说明加锁成功了。
这种分布式的阻塞锁比较适合分布式任务调度场景，但不适合高频次持锁时间短的抢锁场景。按照Google的Chubby论文里的阐述，基于强一致协议的锁适用于粗粒度的加锁操作。这里的粗粒度指锁占用时间较长。我们在使用时也应思考在自己的业务场景中使用是否合适。
1.6. 基于etcd
etcd是分布式系统中,功能上与Zookeeper类似的组件,上面基于ZooKeeper我们实现了分布式阻塞锁，基于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，走抢锁流程。 值得一提的是，在etcdv3的API中官方已经提供了可以直接使用的锁API，读者可以查阅etcd的文档做进一步的学习。
这个过段时间好好学习一下.. 这个云原生和云方面的东西还是很重要的. 即使我已经参与过相关的工作(打杂,并不需要懂)
1.7. 如何选择合适的锁
业务还在单机就可以搞定的量级时，那么按照需求使用任意的单机锁方案就可以。
如果发展到了分布式服务阶段，但业务规模不大，qps很小的情况下，使用哪种锁方案都差不多。如果公司内已有可以使用的ZooKeeper、etcd或者Redis集群，那么就尽量在不引入新的技术栈的情况下满足业务需求。
业务发展到一定量级的话，就需要从多方面来考虑了。首先是你的锁是否在任何恶劣的条件下都不允许数据丢失，如果不允许，那么就不要使用Redis的setnx的简单锁。
对锁数据的可靠性要求极高的话，那只能使用etcd或者ZooKeeper这种通过一致性协议保证数据可靠性的锁方案。但可靠的背面往往都是较低的吞吐量和较高的延迟。需要根据业务的量级对其进行压力测试，以确保分布式锁所使用的etcd或ZooKeeper集群可以承受得住实际的业务请求压力。需要注意的是，etcd和Zookeeper集群是没有办法通过增加节点来提高其性能的。要对其进行横向扩展，只能增加搭建多个集群来支持更多的请求。这会进一步提高对运维和监控的要求。多个集群可能需要引入proxy，没有proxy那就需要业务去根据某个业务id来做分片。如果业务已经上线的情况下做扩展，还要考虑数据的动态迁移。这些都不是容易的事情。
在选择具体的方案时，还是需要多加思考，对风险早做预估。
在我这几年的业务里,几乎很少遇到需要加锁的情况.. 大多需要注意的业务 比如 发放奖励,红包 等这些 都是用队列 慢处理的... 所以学习下也是很有必要的.. 目前同事项目里,用的最多的也是上面Redis里的那种实现方式..
多学习学习.. 恩!以上大部分原文和例子都摘自: https://chai2010.cn/advanced-go-programming-book/ch6-cloud/ch6-02-lock.html 部分地方是我自己理解的时候加入的注释..