人生第一篇技术文章， redis 实现分布式阻塞非争抢锁

[kkk212]

php 好几年了，突然觉得写文章记录很重要。一个能加深理解，一个能技术分享。看 redis 的 brpop 命令时候，突发奇想，这可以实现非争抢阻塞锁。于是有了这篇文章，看看这个锁帅不帅，欢迎拍砖。 在简书上： https://www.jianshu.com/p/6dbc44defd94

[momocraft]

思路不错
如果有防意外的方案可能更好 (我猜如果进程 1 得到锁后释放前崩溃, 其他线程都要永远阻塞)

[Lax]

持🔒的进程挂掉，🔒就丢了

[kkk212]

@momocraft 嗯嗯，是的。redis 队列 pop 空了以后队列 key 就不存在了，完整的方案还需要再想想。

[fighterlyt]

这不是类似于传统的 linux 的 pid 防止并发？ IT 行业已经根深叶茂了，没必要自己从 0 开始，站在巨人的肩上，才能走的更远

[kkk212]

@Lax 是这样 还需要完善

[fighterlyt]

分布式系统，所有操作，除了正常的成功、失败，还必须考虑因为网络分片等原因造成的通信中断等等问题

[kkk212]

@fighterlyt 不局限在 id 并发业务，感觉这是并行转串行的另一种方案。有点同步消息队列的意思，epoll 思想的一种应用。

[kkk212]

@fighterlyt 有个思路就先写出来了，用于项目还需要完善。

[23571113]

https://book.douban.com/subject/30329536/

[kkk212]

@23571113 书不错

[fighterlyt]

@kkk212 并发都是资源竞争

[kkk212]

@fighterlyt 是竞争，用排队思路解决了争抢

[fighterlyt]

@kkk212 资源竞争最传统的解决思路就是排队,临界区，建议锁。你这是重复造了个轮子

[kkk212]

@fighterlyt 造轮子没啥不好，这样才能更好理解原理。不过这还没到造轮子水平，这个思路是借用 redis 的 epoll 机制和队列，实现分布式的同步排队锁。

[fighterlyt]

@kkk212 还有个重要的问题，brpop 并发量大，容易导致读取错误，个人经验，忘了出处了

[kkk212]

@fighterlyt 嗯嗯 这个没想到 我再看看

[pabno]

这样会导致连接一直被占用，redis 默认最大连接数为 10000，当被阻塞的连接过多的时候会影响性能吧

[lasuar]

你这个不是锁了，而是把 redis 当做调度中间件了，只有从 list 中拿到数据的 process 才能往下执行，没有就阻塞，就类似于令牌桶算法或者 go 的 GPM 调度模型。

[kkk212]

@pabno brpop 可以设置最大阻塞时间，不过太高的并发这个思路是不适合的。可以前边再加上限流。

[kkk212]

@pabno 可以设置最大阻塞时间，不过太高的并发这个思路是不适合的。可以前边再加上限流。