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