需要使用分布式锁的场景下，多少人会考虑用 redlock？

两个条件：

1. 当我已经有一个 redis 集群的时候，我直接复用……
2. 为了性能而不是正确性使用分布式锁时

[如果使用 redlock 的话，需要多主部署，为了一个分布式锁更改 redis 部署模式或者多部署一个 redis 集群， 多少有点得不偿失的感觉。]

是的，我之前也想过这个问题，在降本增效的大环境之下，某些不是特别重要的业务又有分布式锁的需求，到底值不值得引入一个组件来解决？投入产出到底划不划算？还是就干脆随便糊弄糊弄正确性就不管了，就看命玩俄罗斯度盘？

并发又不高又要保证正确又不想有资源浪费，后来我就想妈的干脆把数据库做成分布式锁，于是就有了这个开源项目：
https://github.com/storage-lock

项目还在开发中，常用的数据库基本都支持了，后续将逐步支持在任何能存东西的地方都能当做是一把分布式锁，目前还差文档啥的没补全，欢迎大家 flow/star 跟踪项目进度，提出意见啥的。。。

我和 1 楼意见差不多，和 zk 相比的话 redis 好像没什么“非它不可”的情况，考虑正确性的话 zk 更可靠一些。

1. 如果业务本身不用 redis ，没必要为了分布式锁引入 redlock 。用 zk 或者 etcd 更简单。

2. 哪怕业务已经用了 redis ，用单主 redis 或者 redis cluster 也能做锁，只是依赖 redis 可用性而已。对多数业务来说足够了。没必要用 redlock 。

不会使用 redlock ，因为有些情况下，客户端是无法感知到锁被释放了。
分布式锁，各种具体实现不少的，好像没啥情况下是非 redlock 不可的吧。

公司有啥就用啥，比如线上业务已经有部署 zk 集群了，那么分布式锁就用 zk ，除非不满足业务需求再引入其他的技术栈

@adskhf
1 redlock 需要的部署模式和常规的 redis 部署模式不相同，所以可能需要额外部署一套
你说的应该是 redis“单机锁”吧

自从出现过 Redis 锁超时导致的问题以后我现在都只敢用 ZK 锁

redis 还是做好缓存就行了

@zeonluang 没太懂，为啥部署模式不太一样？

我用的不是单机锁，就是用于不同实例间同步