这是一个创建于 1342 天前的主题，其中的信息可能已经有所发展或是发生改变。
Redis 根本就不是设计出来干这个的，为什么网上这么多垃圾文章讲这个？
老老实实用 ZK 或者 ETCD 不好吗？
感觉大量的垃圾技术文章的内容都可以总结为三句
1 我没读文档瞎 jb 用，结果不符合预期。
2 出 bug 了受不了才老老实实读文档，原来是我用的不对。
3 按照文章老老实实的写代码，终于对了。
看多了会觉得中文技术社区真是垃圾堆。
老老实实用 ZK 或者 ETCD 不好吗？
感觉大量的垃圾技术文章的内容都可以总结为三句
1 我没读文档瞎 jb 用，结果不符合预期。
2 出 bug 了受不了才老老实实读文档，原来是我用的不对。
3 按照文章老老实实的写代码，终于对了。
看多了会觉得中文技术社区真是垃圾堆。
第 1 条附言 · 2021-03-08 23:09:37 +08:00
没发内容是我不对。但是白天毕竟是要上班的。
首先讲一下观点。
从分析需求开始
1 需不需要分布式锁？
大部分时候是不需要分布式锁的，如果你选择了 AP，那么我的理解是你可以容忍一定的数据不一致，那么你不需要分布式锁。因为一个正确性的分布式锁是很“重”的一个开销，AP 的场景一般承受不了。所以如果需要分布式锁，那么一定是一个 CP 的场景，就是说需求是为了一致性而牺牲一定的可用性。
很多网友说，我在要求 CP 的场景用 Redis 我也没咋地。我说是，那是你命好，交的学费不够多。
如果你一个订单 1000 万美金，你会给老板那说，我这个系统只有 0.0001 的概率会出问题，你信不信你工作没了。
---
如果你有 AP 又要用到分布式锁，那请你分享一下场景和设计思路，让我们长长见识。
这里开始我们的前提是 CP
2 Redis 是这个场景正确的选择吗？
首先单机 Redis 排除，因为就不是分布式锁。
那么接下来就是 Redlock 。
用 Martin Kleppmann 关于 Readlock 的评价
https://martin.kleppmann.com/2016/02/08/how-to-do-distributed-locking.html
我擅自总结一下，
第一段讲分布式锁的用途
第二段讲这个算法的漏洞
第三段讲用一个 token 做 fence 是不是就可以救回来了呢》
第四段说不是的，因为 redis 作者做了错误的设计假设，这个系统的漏洞是无法补救的。
就是他的假设是基于整个系统是一个半同步的状态。semi-sychornous
这些假设对于分布式系统设计稍有涉猎就可以看出十分幼稚。
（注意，我们的标准是 CP ！)
Redis 作者的回复我也看了。
http://antirez.com/news/101
很遗憾，这个兄弟基本上不懂分布式系统的理论。所以他的回答也没什么很大的价值。
一句话，Redis 的分布式锁。你要用就要 5 个节点，那既然你都有 5 个节点了，为什么不用 ZK 和 redis 。
3 ZK ETCD 和 redis 本质设计区别是什么？
核心在于，ZK 和 ETCD 一开始就是为了解决分布式系统核心的共识问题（ consensus ）而设计开发出来的软件，Redis 不是。
ZK 有 Zab，ETCD 有 raft 这些共识算法来解决共识问题。 不了解这些基础知识的希望了解一下。
4 我不是研究分布式系统的博士。但是我是搞数学的。数学和分布式系统的相同点就是
一个算法在没有数学证明之前，总是要假设它是错的。没有证明，不管多少人说是对的，也是不行的。
5 对我的英语水平的评价不想回应。
首先讲一下观点。
从分析需求开始
1 需不需要分布式锁？
大部分时候是不需要分布式锁的，如果你选择了 AP，那么我的理解是你可以容忍一定的数据不一致，那么你不需要分布式锁。因为一个正确性的分布式锁是很“重”的一个开销，AP 的场景一般承受不了。所以如果需要分布式锁，那么一定是一个 CP 的场景，就是说需求是为了一致性而牺牲一定的可用性。
很多网友说，我在要求 CP 的场景用 Redis 我也没咋地。我说是，那是你命好，交的学费不够多。
如果你一个订单 1000 万美金，你会给老板那说，我这个系统只有 0.0001 的概率会出问题，你信不信你工作没了。
---
如果你有 AP 又要用到分布式锁，那请你分享一下场景和设计思路，让我们长长见识。
这里开始我们的前提是 CP
2 Redis 是这个场景正确的选择吗？
首先单机 Redis 排除，因为就不是分布式锁。
那么接下来就是 Redlock 。
用 Martin Kleppmann 关于 Readlock 的评价
https://martin.kleppmann.com/2016/02/08/how-to-do-distributed-locking.html
我擅自总结一下，
第一段讲分布式锁的用途
第二段讲这个算法的漏洞
第三段讲用一个 token 做 fence 是不是就可以救回来了呢》
第四段说不是的，因为 redis 作者做了错误的设计假设，这个系统的漏洞是无法补救的。
就是他的假设是基于整个系统是一个半同步的状态。semi-sychornous
这些假设对于分布式系统设计稍有涉猎就可以看出十分幼稚。
（注意，我们的标准是 CP ！)
Redis 作者的回复我也看了。
http://antirez.com/news/101
很遗憾，这个兄弟基本上不懂分布式系统的理论。所以他的回答也没什么很大的价值。
一句话，Redis 的分布式锁。你要用就要 5 个节点，那既然你都有 5 个节点了，为什么不用 ZK 和 redis 。
3 ZK ETCD 和 redis 本质设计区别是什么？
核心在于，ZK 和 ETCD 一开始就是为了解决分布式系统核心的共识问题（ consensus ）而设计开发出来的软件，Redis 不是。
ZK 有 Zab，ETCD 有 raft 这些共识算法来解决共识问题。 不了解这些基础知识的希望了解一下。
4 我不是研究分布式系统的博士。但是我是搞数学的。数学和分布式系统的相同点就是
一个算法在没有数学证明之前，总是要假设它是错的。没有证明，不管多少人说是对的，也是不行的。
5 对我的英语水平的评价不想回应。
第 2 条附言 · 2021-03-08 23:10:36 +08:00
我看到有人提了说一下
DDIA 《数据密集型程序设计》 Martin Kleppmann 著
后端必读，京东有卖。懂得都懂。工作了看每年都有新体会。
lamport 的论文
Time, Clocks, and the Ordering of Events in a Distributed System
https://lamport.azurewebsites.net/pubs/time-clocks.pdf
开山之作，不知道不应该。
raft 作者的博士论文，有时间可以读一下。英语很简单，把一个共识算法的细节都讲的很清楚。
这非常了不起。
https://web.stanford.edu/~ouster/cgi-bin/papers/OngaroPhD.pdf
如果我提的概念你一点都没听过，兄弟听一句劝，不懂可以学，千万别不懂瞎 jb 搞。
DDIA 《数据密集型程序设计》 Martin Kleppmann 著
后端必读，京东有卖。懂得都懂。工作了看每年都有新体会。
lamport 的论文
Time, Clocks, and the Ordering of Events in a Distributed System
https://lamport.azurewebsites.net/pubs/time-clocks.pdf
开山之作，不知道不应该。
raft 作者的博士论文，有时间可以读一下。英语很简单，把一个共识算法的细节都讲的很清楚。
这非常了不起。
https://web.stanford.edu/~ouster/cgi-bin/papers/OngaroPhD.pdf
如果我提的概念你一点都没听过，兄弟听一句劝，不懂可以学，千万别不懂瞎 jb 搞。
 |
101
wmwmajie 2021-03-08 23:36:56 +08:00
用楼主的例子，如果一个订单 1000 万美金的系统你会以分布式锁来作为最终的成交判定么？
所以 0.0001 的错误概率有什么问题？ |
 |
102
hotsymbol 2021-03-08 23:45:12 +08:00  1
建议查看一下楼主的美国博士是否是造假的。Redis 官方文档上就有。为什么不看 ？是因为看不懂英文吗 ？
|
 |
105
DoctorCat 2021-03-08 23:55:02 +08:00
问：老老实实用 ZK 或者 ETCD 不好吗？
答：部分公司的码农并不会玩分布式中间件，也缺少相关的运维经验，固 Redis 解决问题啦，多快好省。 非学术讨论，达到项目效果 Run 起来时对于部分开发而言逻辑就是这么简单、朴素。 |
 |
106
liuhuan475 2021-03-09 00:15:01 +08:00
看楼主言论，分布式锁用 MySQL 再适合不过了
|
 |
107
uselessVisitor 2021-03-09 08:03:46 +08:00
@fuis 那你为什么还来垃圾堆里呢？ Block 了 阴阳怪气
|
 |
108
Makuma 2021-03-09 08:13:06 +08:00
既然楼主知道 lamport，也应该知道 raft 用了 lamport 推荐的 TLA 证明安全性，那楼主手动用 tla 证明 redis 方案不靠谱不就行了
|
 |
109
sampeng 2021-03-09 08:25:32 +08:00 via iPhone 2
其实我也一直纳闷为什么动不动就是拿 redis 做队列，动不动就是 redis 做分布式锁。还满是优越脸…那您 redis 崩了别来找我啊，云端 redis 运维够简单了吧，中断 30s 够快了吧。抱歉，就是有人要把 redis 当核心外部依赖…我昨天一看，所有服务都是这样，在 k8s 的环境下，如果 redis 挂了，全部雪崩…………
|
|
110
sampeng 2021-03-09 08:29:00 +08:00 via iPhone
还有都贴官方推荐，所以用。那么问题来了，数据不一致的时候，哪怕一辈子就一次，偏偏几千万订单。你猜是你负责还是所谓的 redis 官方负责？
我一直对这种以内存为主的单机行为分布式锁抱有怀疑。内存天然不靠谱。连个分布式协议都没有…我没想明白为什么这么多人觉得这个玩意是绝对可靠的 |
 |
111
imjamespond2020 2021-03-09 08:44:00 +08:00 via Android
分布式锁感觉可以用比特币的去中心化思想来实现一下？
|
 |
113
pisc 2021-03-09 09:01:56 +08:00 via Android
@Makuma tla+一般是作者自己去证明自己的模型的正确的，才能令人信服，而事实是，还没用上 tla+，人反对者都给出“不靠谱”的时序了
|
 |
114
ryd994 2021-03-09 09:07:37 +08:00 2
@nagatoism
@sampeng 1000 万美金的系统还用 Redlock 那是自己作死。人家文档里都说了无法保证 C，不看文档能怪谁。上千万的系统没个设计文档没个安全审计，逗谁呢？都搞上千万的分布式系统了，还请不起一个专业搞分布式的来审计一下算法？技术负责人干什么用的？就是拍板负责用的啊。谁是老板谁负责。 什么情况下可以用？ 1. 东西不值钱，不存在你说的 1000 万。 2. 活该傻逼不看文档 3. 不要求强一致，再维护一套 ZK 集群又太麻烦。比如楼上某些人提到的，第三方 API 限制频率。偶尔 miss 一次不是不能接受，但是不挡一下又不好。既然已经在用 Redis，那用个现成的 Redlock 实现也是顺理成章的事情。 说到底：不看文档就瞎用自己不懂的算法那就是活该。谁用谁负责。 |
 |
115
siweipancc 2021-03-09 09:08:08 +08:00 via iPhone
有点……意思:D
|
|
116
ryd994 2021-03-09 09:16:15 +08:00
@Makuma 要证明不安全只需要一个反例。
要证明安全则必须要靠推导。所以真的需要绝对正确的软件，那得先写出数学推导，然后把数学算法转换成代码，再证明数学模型和代码等价。这样做是可以保证没用 bug 的（只要硬件不出问题）。 当然，实际上需要这么干的软件非常非常少。大部分程序员就是写几个 test case，然后上线的时候灰度上线就算了。如果真的是这个行业的人，也不可能不看文档，只看一篇百度就瞎 JB 用。 @nagatoism 你说的垃圾技术文章问题，和中文无关。英文的垃圾文章也多了去了。只不过作为中文 native speaker，既然都在看英文文章了，大部分还是会去看官方文档的人。Aka，英文是个门槛。 但是如果完全脱离中文，直接就搜英文，你有非常大的概率会搜到垃圾英文文章。 比如有人今天手上就有个 redis，就想要个锁，你猜 Google 第一条是啥？ 这是中文的锅吗？这明明是不看文档的锅。 |
 |
117
lzlee 2021-03-09 09:17:49 +08:00 1
神仙打架, 先留个名
等我学明白也来加入 battle |
|
118
sampeng 2021-03-09 09:21:50 +08:00 via iPhone
@ryd994 我觉得 lz 的意思不是无脑 redis 锁，是中文环境下的文档搞得好像只有这个方案，etcd/zk 的分布式锁成了原罪一样。实现需求不是非黑即白。还是要考量业务因素。但我比较反对的是说大额交易才要考虑 cp 。这点我观点跟 lz 相同，和钱打交道只能是 cp 不能考虑 ap 。哪怕只有 1 毛钱的东西。
|
 |
119
weizhen199 2021-03-09 09:27:38 +08:00
/吃瓜
好复杂，oracle 一把梭（锁 吧 |
 |
120
itskingname 2021-03-09 09:29:12 +08:00 via iPhone 23
我觉得楼主主要的问题就是因为楼主是搞数学的，而不是搞工程的。搞数学的人有个什么问题？搞数学的人，他们总是追求绝对准确，绝对一致，而不考虑要达成这个条件需要付出的成本。而做工程的人关注的是在误差范围内，在可接受的范围内，成本最低。Redis 做分布式锁确实无法保证一致性，但是在什么样的并发情况下才能暴露出这个问题？项目如果达不到这个量级为什么不行。楼主一来就提一个什么一千万的系统。系统都是从最小系统一层一层搭建起来的，一开始甚至连锁都没有，随着业务的增加而逐渐增加组件。业务规模在一定范围内，Redis 做分布式锁是最经济最有效最低成本的方式。等到业务规模继续扩张，再上 etcd 。楼主搞数学的这批人，就是一上来就想搞个可以用一万年的完美系统。一上来就 cap 分析来分析去，不考虑工期，不考虑成本，不考虑现阶段用不用的上。很多公司就是这样被拖死的。
|
 |
121
Blueming 2021-03-09 09:31:44 +08:00 3
楼主就是来秀优越的
先捶 Redis，再捶作者 然后假设会有 0.0001 的几率出问题，自己也不给出数据证明 后面再装 X 说一句“一个算法在没有数学证明之前，总是要假设它是错的。没有证明，不管多少人说是对的，也是不行的。” 你咋不给个你 0.0001 怎么证明来的呢？好话坏话全给你说了呗 说完就不假设 ZK 和 ETCD 的出错几率了，绕过直接谈设计初衷。寻思这俩在生产环境中在你看来是 100%不会出错咯？ 真有你的。 |
 |
122
no1xsyzy 2021-03-09 09:37:08 +08:00
@wucao219101 #1 @Xbluer #2 放的同一个链接非常充分地证明了 OP 的观点…… 我不知道怎么有脸说 “官方的推荐用法怎么是骚操作？” 的？
哦原来是不懂英文的虫族，那我稍微作点人族的翻译工作。 > 因为一直有人拿 Redis 以各种各样的方式错误地实现分布式锁，所以我们还是弄个官方的分布式锁。 > 那我们官方摆个稍微复杂稍微有效的规范化的实现搁这儿了，你们来看看这个算法咋样？ |
 |
123
trlove 2021-03-09 09:57:04 +08:00 4
实际上提出这些存在的问题是很有必要的，但我觉得 lz 有点戾气太重。首先不是所有场景都像楼主说的 1000 万美金的订单那么夸张。有很多系统 没那么庞大 也不是要求数据必须百分百正确 可以容忍一定的错误 但是 又想尽可能最大程度的正确 这时候加个 redis 的锁就很合适了 一是基本很少有系统不用 redis 现成的 redis 拿来就用 很方便 如果另外搞 zk/etcd 又得多维护一个组件 还得多搞几台机器 这都是成本 搞技术的不是人人老板啊 可以随心所欲随便加机器加组件 如果可以 谁不想搞个几百台机器来个超大系统 来提升自己呢？就像现在到处都是文章介绍 jwt 做登录 token 的。我一开始就觉得很鸡肋。因为我觉得 jwt 所谓的 serverless 就是鸡肋的东西。jwt 放出去，服务器控制不到。但是很多系统又有踢下线功能，多处登录只允许存在一个，以及很多场景下我可以随时终止这个 token 的生命。很明显，如果用 jwt 要做这种 必然需要另外搞一个值存储在服务端和 jwt 对应 才能终结 jwt 那这样所谓的 serverless 就没了意义。 那是不是 jwt 就没意义了？并不是。很多系统不一定就需要踢下线 需要服务端终结 jwt 的生命，亦或者给第三方服务做授权，亦或者做服务间的 token 也都行。技术是服务业务的，业务推动技术的发展。很多时候考虑技术选型不是看技术多么完美，而是要看技术和所要做的东西的契合度。抛开业务本身去讨论一个技术的完美度 这种情况可能只存在于学校了……
|
|
124
ryd994 2021-03-09 09:58:20 +08:00 4
@sampeng Google：distributed lock library
1. Distributed locks with Redis – Redis 2. madelson/DistributedLock: A .NET library for ... - GitHub 其中 Redis 部分就是 Redlock 3. Kleppmann's blog 之前提到的 4. Everything I know about distributed locks | by Davide Cerbo 推荐了 ShedLock, 和 ZK 、ETCD 没细看 ShedLock，但是看起来不是 Redlock 衍生物 5. Distributed lock manager - Wikipedia Redis can be used to implement the Redlock Algorithm for distributed lock management.[10] 呵呵 6. The Top 7 Distributed Locks Open Source Projects 猜猜 Redlock 出现了几次 7. Distributed Locks are Dead; Long Live Distributed Locks 看起来是没啥问题。 8. Everything I Know About Distributed Locks - DZone Database 和 4 一样 9. Building Distributed Locks with the DynamoDB Lock Client 没有细看。看到 heartbeat every 10 seconds 就说明和 Redlock 是一个意思 10. distributed locking - npm search 猜猜这里面有几个 redis ？又有几个 Redlock ？ 这就是 Google 第一页。你觉得这够不够垃圾？ 垃圾文哪都有，英文社区也不比中文社区少。 至于多少钱需要考虑可靠性的问题，我就提几个： 1. 阿里抢月饼 2. 2010 flash crash，有一说是高频交易程序出 bug，或者 fat finger，然后触发做市商程序挂起。请问这种事情是多少概率？ 3. Ariane 5，就问这个 bug 贵不贵？ 事实就是，这个世界并不是这么的可靠。有相当多的人其实根本无法理解其重要性。同时也有相当多的人理解但选择忽视。当然咱不是故意去写 bug 。但是如果一共也就几万块钱的系统，管的是不那么重要的东西，你觉得老板会希望你多花一个月时间去实现一个可以提供形式验证的软件吗？你一个月工资也要几千了。 还有电商搞促销活动，抢占市场重要还是不被撸 bug 重要？大不了事后砍单就是了。甚至还有故意塞漏洞就是吸引你来撸的。 任何事情，都有其机会成本。实践中，重点不是绝对无 bug，而是在某些关键节点做好 damage control，同时完善日志，确保出了问题以后能够查到原因。很多时候，这就够了。 |
 |
125
fenglangjuxu 2021-03-09 10:00:09 +08:00
etcd 没有 redis 能扛得住高并发 我觉得
|
 |
126
glfpes 2021-03-09 10:06:25 +08:00
我觉得这篇文章可以看看： https://zhuanlan.zhihu.com/p/73807097
|
 |
127
fuis 2021-03-09 10:06:28 +08:00
@beichenhpy 因为嘲讽像你这样的菜鸟很爽，连楼主说的是对是错都分不清，大概这就是“工程师红利”吧
|
 |
128
vincent7245 2021-03-09 10:09:23 +08:00 1
@itskingname 太同意你的观点了，工程和科研是两码事，我带项目的时候是严禁那些理论派直接参与的，他们可以给出建议，但是 绝对不能让他们有太多的话语权。很多时候就是，他们说的都对，但是在现有的资源下不可能实现。
|
|
129
ryd994 2021-03-09 10:16:51 +08:00 4
@itskingname
@trlove 非常同意 我是材料工程和 CS 双学位。目前也是从事系统底层的工作，实践为主。说几个事情，恶心一下楼主： 1. 工程课教授：c 是一个经验常数，一般取 3 2. 工程课教授：这个公式的结果通常比实际稍大，但是没关系，我们下一步会取 10 倍安全余量 3. 工程课教授：这一大坨公式我们直接约等于 3 4. 老板：这个 corner case 你先别管，上线再说 5. 老板：这个 bug 我们都知道，但是很少见而且后果很小，先不修它 6. 老板：灰度上线跑了一个月了，有没有问题？没问题我们就放量了。 7. 我们之前都好好的啊，怎么到你这里就出 bug 了？ 楼主呢，无非是想掉个书袋子，秀秀优越感。诚然，瞎 JB 用的傻逼是有，还不在少数。但是： 1. 如我楼上所说，垃圾文章到处都有，不局限于中文 2. 工程实现很多时候就是这么脏 3. 闻道有先后，术业有专攻 @Blueming 证明有 bug 很简单：举出一个 bug 就行。证明没有 bug 则是恶魔的证明。除非形式化论证，否则无法保证没有 bug 。 ZK 和 ETCD 是有设计模型的。虽然代码可能有 bug，但算法理论上是没问题的。 而 Redlock 的算法设计就是没有 C 的。 |
|
130
ryd994 2021-03-09 10:22:26 +08:00
@fenglangjuxu 如果你需要的是高并发系统，那我非常怀疑你是否真的需要绝对的 C 。
同时我也很怀疑你是否真的应该用分布式锁实现这个目的。你去看实际生产中用的多的分布式的储存系统，以高性能为卖点的，其中有多少是强一致，又有多少用的是锁。不用锁，也有很多办法能保证程序的正确与高效，如何选择合适的分布式算法，这需要相关领域的知识。 该请人的时候就得请人。 |
 |
131
Slartibartfast 2021-03-09 10:27:09 +08:00 via iPhone
|
 |
132
ward56 2021-03-09 10:28:39 +08:00
没有最好的系统软件，只有最适合自己的系统软件。
|
 |
133
Citrus 2021-03-09 10:30:57 +08:00
小兄弟，这个世界并不是非黑即白的，不要走极端。所有的问题都应该放到合适的场景下去考虑，而不是像你这样一棒子直接全部打死。
|
 |
134
CRVV 2021-03-09 10:33:13 +08:00
@ryd994
ZooKeeper 和 etcd 的设计模型是说它自己的若干台机器之间要怎么通讯，但这里说的“分布式锁”是说 client 和 etcd/ZooKeeper/Redis 之间要怎么通讯，这是两码事。 这个事情早就有人讨论得很清楚了，给 “觉得中文技术社区真是垃圾堆” 的楼主贴一篇 http://zhangtielei.com/posts/blog-redlock-reasoning.html http://zhangtielei.com/posts/blog-redlock-reasoning-part2.html 其中对 Martin Kleppmann 的观点有实质性反驳作用的其实是 ZooKeeper 也一样存在 Martin Kleppmann 说的问题 |
 |
135
jiangzhizhou 2021-03-09 10:35:15 +08:00
@ryd994 @Slartibartfast
@hxndg 其实 AWS 提出了新的 PIE 理论，可能比 CAP 更加靠谱？ ?t=2608 我在很大的基础分布式组工作过（ AWS 核心服务），见过解决这些问题的世界级别的方案。其实都有很多的 Trade Off，没有啥东西是 kill everything 。 越是见了多了，感觉自己越菜。 |
 |
136
iseki 2021-03-09 10:40:05 +08:00 via Android
什么场景用什么东西，“一千万的订单出了问题谁负责”，处理钱的场景你用一个没有强一致的东西出了问题你说谁负责。
|
 |
137
MonoBiao 2021-03-09 10:40:17 +08:00
插个楼，看了看，我果然还是太菜了
|
 |
138
yamasa 2021-03-09 10:51:03 +08:00
工程当然是又脏又臭，充满 tradeoff 的 rabbish, 怎么能弄脏咱们高贵的数学家写公式的手？
|
|
139
trlove 2021-03-09 10:56:45 +08:00
@ryd994 是的啊 事实上服务业务时候是很多很恶心事情的。而且如楼主所说，即使各种技术文章分享 redis 的锁，那说明这个东西满足大部分人需求了，并且人家也只是分享他做过的案例，有他的场景和和限制在那里。作为观看者，如果不能分析出这个案例的利弊，那就是我们观看者的问题，而不是分享技术的那些人的问题，不能去怪别人为啥到处写 redis 锁而不写 etcd/zk 。这就很奇怪了。另外我觉得如果楼主单纯是想讨论 redis 锁对比 zk 和 etcd 的劣势，标题应该写 zk/etcd 为什么比 redis 锁好，或者 为什么 redis 锁不如 zk/etcd ？ 这样才是一个合格的讨论某种技术的优劣问题 而不是上来就说 redis 锁是骚操作……
|
 |
140
love2020 2021-03-09 10:59:02 +08:00
大佬们发布的关键词，，我一个都看不懂。。。
|
 |
142
9684xtpa 2021-03-09 11:35:45 +08:00
在业务角度，多数强一致性的东西，redis 分布式锁+mysql 唯一键都可以解决，我何必要额外加一套组件，多一些维护成本呢
|
 |
143
4771314 2021-03-09 11:43:39 +08:00
看业务场景吧，一些简单的业务场景下，redis 不失为一个选择，而且 redis 实现起来真的很简单，如果说你的系统有 999999999 的可靠性要求，当我不存在
|
|
144
4771314 2021-03-09 11:45:08 +08:00 1
你们轻点锤，lz 简历都下架了
|
|
145
wmwmajie 2021-03-09 11:55:54 +08:00
@nagatoism 你可能没太明白我的意思，你举一个场景，一个订单 1000 万美金，在什么情况下会导致这个订单出错。
通过分布式锁来判定这个订单是否支付成功还是下单成功？ |
 |
146
another1025 2021-03-09 12:12:51 +08:00 1
就当前环境来说，楼主说的是事实，实际上愿意去了解背后原因的人真的非常稀少，人们只想要现成的解决方案。既然 Redis 作为缓存组件几乎成了事实标准，那么再用它来实现分布式锁就显得顺理成章。只要官方说能用，那我们就用，官方说不行，我们就换。谁也说不准未来会不会又出现什么 xxdis 呢。赞赏楼主的态度，看到垃圾堆我们当然可以义愤填膺，也要顺手带走一两个易拉罐，免得它越堆越高。
|
|
147
Slartibartfast 2021-03-09 13:33:15 +08:00 via iPhone
@jiangzhizhou 工程的世界比较复杂，接触过国内某两个大厂的多套核心分布式系统，也是充斥着 tradeoff 。
使用前必须得能够接受这些 tradeoff，必要时还得调整自己的代码逻辑去适配。 |
 |
148
iyaozhen 2021-03-09 13:53:17 +08:00 2
楼主说的没错
但工程方面真的需要很多妥协，有人说为什么锁和队列都喜欢用 redis 。因为一般业务没那么大的场景，而且不一定都是钱相关 主要是 redis 简单，单机就能抗很大的流量 比如用 zk，实际用过就知道，本身服务故障的几率比 redis 大多了，有时候天生分布式反而是它的缺点，运维成本搞 队列也类似比如用 kafka 、RocketMQ 抛开本身集群的运维，还得知道很多概念，用错了问题更大，redis 的 LPUSH，RPOP 简单很多 这么说的，大部分工程师能把业务需求整明白就很不错了 |
 |
149
luikore 2021-03-09 14:28:43 +08:00
> 首先单机排除
但实际 99% 场景都是用单机 redis 锁啊。 分布式锁是为了序列化多机器访问共享资源，多台机器访问一台 redis 的锁就不是分布式锁了？ 如果 redis down 我大不了都 acquire lock 失败 -- 但纯用来锁的单机 redis 比你的 zk 集群稳多了。 |
|
150
jiangzhizhou 2021-03-09 15:13:47 +08:00
@iyaozhen 说白了其实小公司根本没那么大的流量，根本不用管理什么集群。我很好奇，为什么不上云解决这个问题呢？那天业务暴增了也能扛得住。
|
 |
151
ZSeptember 2021-03-09 18:52:04 +08:00
选择了分布锁，基本是就是要求 CP 了，既然 CP 了，那么单机 redis 好像也没啥问题。所以，用单机 redis 实现分布锁总没问题了吧（不加超时）。
当然，尽量系统设计的时候就要避免分布式锁，超时导致的问题无解吧。 |
 |
152
v2Geeker 2021-03-09 19:51:23 +08:00
楼主说的好像并没有错，而且，既然都上了分布式锁，还要高并发？这过分了吧。🐶
|
 |
153
ujued 2021-03-09 21:08:55 +08:00 via iPhone
> 首先单机 Redis 排除，因为就不是分布式锁。
从某些角度来看，单节点也是分布式应用，复合 CP 设计。 多节点的 CP 系统，比单节点多了一个自动故障转移。 试想很低概率会手动解决的问题是不是也很好接受呢？ 这么来看，有些大神的单节点 redis 分布式锁也很合理呢。 单节点漂移术..... |
 |
154
hallDrawnel 2021-03-09 21:47:07 +08:00
你就不能有条有理的说出来，非要用嘲讽的语气和吵架的态度？
|
 |
155
leeg810312 2021-03-09 22:11:54 +08:00 via Android
@v2Geeker lz 完全不对，他根本没有给出必须 zk 的理由。他骂街式口吻以工程应用角度提出质疑，却以理论推导来反对其他人以实际使用为论据的反驳，根本就是牛头不对马嘴，他完全就是为了反对而反对。为了反对而举的例子也是可笑至极，1000 万美金订单会因为 redis 分布式锁的低概率潜在问题而丢了根本就是系统设计错误，能有 1000 万订单的分布式系统一定会有多重机制保障的设计。别人反问他是否会以分布式锁做最终判定，他还死鸭子嘴硬，他就会。最终还是没有给出必须用 zk etcd 的证明。不好好研究学术，非得来指导工程实践，脑子有问题
|
 |
156
lewinlan 2021-03-09 22:18:32 +08:00 via Android
理论是垃圾，但架不住用的人多。
比如我就嘲讽 java,嘲讽 php,但依然大把人用，大把人招。 这的确是工程的妥协…… 反正有啥用啥就好了，尽人事，听天命：） |
|
157
iyaozhen 2021-03-10 13:31:33 +08:00
|
 |
158
lateautumn4lin 2021-03-12 17:17:04 +08:00
有点意思，得深入研究下
|
 |
159
jimmyismagic 2021-03-15 20:25:20 +08:00
谢谢楼主，有争论才有进步
|
Select Language