关于redis分布式锁的问题. 如果没抢到锁,那么应该怎么做,一直重复抢锁的操作吗?

Question

新手初学redis,尝试redis锁的时候,go代码如下: func main() { client := redis.NewClient(&redis.Options{ Addr: "localhost:6379", }) for i := 0; i < 100; i++ { go func() { for { //一直 for 循环抢锁吗? ok, err := client.SetNX("sync", true, time.Second*5).Result() if err == nil && ok { res, err := client.Get("num").Result() fmt.Printf("num : %s\n", res) num, err := strconv.Atoi(res) err = client.Set("num", num+1, 0).Err() _, err = client.Del("sync").Result() if err != nil { log.Println(err) } break } //time.Sleep(time.Millisecond * 10) } }() } time.Sleep(time.Second * 20) } 代码中我开了 100 个协程抢锁,操作一个数据.我的疑问是,当一个协程抢到了这个 sync 锁,那么其他的 99 个协程, 都一直在不停的在一个循环中重复抢锁吗?这样子是否会对redis产生大量的无意义的请求...网上搜了一下相关的实现demo代码,发现都是类似的 while(true) { // xxxxxxx } 进行抢锁....所以很疑惑,若是真实生产环境也是这样实现嘛....还是我一开始就错了...如果有相关资料或者是搜索关键词,还望大佬指点一二.

Answer 1

看你要实现什么样的锁，或者基于什么样的使用场景，比如说排它锁，redis就实现不了，排它锁在获取不到锁的情况下会阻塞进入等待队列。在其他进程释放锁时会通知该进程再去获取锁，redis不提供这种基于key的通知机制，所以他实现不了排它锁。不过分布式排它锁，可以由Zookeeper实现。

另外一种分布式锁的实现方式是通过乐观锁和自旋的实现方式，就是你说的那种方式，不过一般会设置超时时间，也就是redis设置key的ttl。这样不至于进程一直等待下去。这种锁适应于锁内操作时间比较短，锁竞争不是那么激烈的情况。

你说的那种100个进程抢锁的情况，竞争这么激烈，还是用排它锁比较好。

Answer 2

这个原因充分说明了要项目驱动学习。
只有你知道具体的项目的场景，才可以决定自己这个锁怎么处理。
比如，你如果抢不到资源就必须等待，而且是同步请求，那么必须等待。
比如，你如果可以接受若一致，就可以考虑等待多久锁，然后放弃，记录日志或者其他补偿机制。
当然这个就类似于 ReentrantLock 里面的 tryLock 和 tryLock(long timeout, TimeUnit unit) 的区别

Answer 3

需要带锁的操作一遍不会这样的逻辑。。。
比如缓存数据的更新。

1.取到锁的人去查数据库并更新数据
2.未取到锁的要么直接返回空，要么就是要设置二级缓存，把二级缓存的数据返回。。

大家都一直要拿到同一个锁，应该没有这种操作吧？

具体还是要有业务逻辑来进行代码编写，不然没有意义