这是一个创建于 216 天前的主题，其中的信息可能已经有所发展或是发生改变。
如果使用 redlock 的话，需要多主部署，为了一个分布式锁更改 redis 部署模式或者多部署一个 redis 集群， 多少有点得不偿失的感觉。
提出这个问题肯定会有人拿 redis 和 zk ，etcd 对比。我的本意并非引战，而是想知道 redlock 这个解决方案是否有我没看到的“闪光弹”，在什么场景下非它不可。
ps：我日常开发中，需要用锁时也是 codis“单机锁”一把锁。不考虑啥主从同步失效（笑）
 |
1
adskhf 216 天前
两个条件：
1. 当我已经有一个 redis 集群的时候，我直接复用…… 2. 为了性能而不是正确性使用分布式锁时 |
 |
2
CC11001100 216 天前  1
[如果使用 redlock 的话，需要多主部署，为了一个分布式锁更改 redis 部署模式或者多部署一个 redis 集群， 多少有点得不偿失的感觉。]
是的，我之前也想过这个问题，在降本增效的大环境之下，某些不是特别重要的业务又有分布式锁的需求，到底值不值得引入一个组件来解决？投入产出到底划不划算？还是就干脆随便糊弄糊弄正确性就不管了，就看命玩俄罗斯度盘？ 并发又不高又要保证正确又不想有资源浪费，后来我就想妈的干脆把数据库做成分布式锁，于是就有了这个开源项目： https://github.com/storage-lock 项目还在开发中，常用的数据库基本都支持了，后续将逐步支持在任何能存东西的地方都能当做是一把分布式锁，目前还差文档啥的没补全，欢迎大家 flow/star 跟踪项目进度，提出意见啥的。。。😀 |
 |
3
lanlanye 216 天前
我和 1 楼意见差不多，和 zk 相比的话 redis 好像没什么“非它不可”的情况，考虑正确性的话 zk 更可靠一些。
|
 |
4
swulling 215 天前 via iPhone
1. 如果业务本身不用 redis ，没必要为了分布式锁引入 redlock 。用 zk 或者 etcd 更简单。
2. 哪怕业务已经用了 redis ，用单主 redis 或者 redis cluster 也能做锁，只是依赖 redis 可用性而已。对多数业务来说足够了。没必要用 redlock 。 |
 |
5
burymme11 215 天前
不会使用 redlock ，因为有些情况下，客户端是无法感知到锁被释放了。
分布式锁，各种具体实现不少的，好像没啥情况下是非 redlock 不可的吧。 |
 |
6
vincent7245 215 天前
公司有啥就用啥，比如线上业务已经有部署 zk 集群了，那么分布式锁就用 zk ，除非不满足业务需求再引入其他的技术栈
|
 |
8
SoviaPhilo 215 天前
自从出现过 Redis 锁超时导致的问题以后我现在都只敢用 ZK 锁
redis 还是做好缓存就行了 |
Select Language