@szkoda 看到了, 我仔细研究下, 之前就过了一眼.. 3q3q.

直接拔的确很危险, 可能导致面部神经异常, 面部瘫痪等. 但我有时候还是直接拔..

@xkeyideal 老哥,还是没看到==, 求赐教

@owt5008137 同一个锁是加在同一个目录下的哈

@xkeyideal 😱 我再看看吧, 我就简单看了下.. 3q

@xkeyideal 我看的这个, https://github.com/etcd-io/etcd/blob/master/clientv3/concurrency/mutex.go , 大佬带带我, 我疑惑了大半天了

@xkeyideal 大哥你看过源码 clientv3 的 mutex 源码么??? 他那个锁只是一个 cas 乐观锁,连重试都没有. cas 一下, 没获取到就返回一个 error

@AzadCypress 对的,revision 是全局递增的.

的确可以随便写一个值到目录下, 比如 uuid. 简单方便.

这样看下来 etcd 没法自动生成顺序节点名称了, 只能客户端写入一个唯一名称的节点了

@AzadCypress 我没看到 etcd 有顺序节点这个概念或者相关的概念, 是我看漏了啥么??

你这个意思是在 /lock 下写入自己的节点, 但每个节点 key 保证唯一, 然后按他们的 revision 来实现 zk 有序节点的概念么?
照你这么说我想了想是可以实现了.

但还有个问题就是这个 key 得客户端保证在所有客户端中全局唯一, 还有没有不用客户端去生成这个全局唯一得 key 的方案呀?

@owt5008137 老哥我是想问有没有像 zookeeper 实现分布式锁只用监听顺序节点的前一个节点, 前一个节点删除只用通知一个客户端, 而不是像 etcd 这样所有的都监听这个节点, 这个节点删除的时候需要通知所有监听它的客户端.

=_=

google 了一波, 清一色 说通过 revision 机制.. 有大佬能具体解释下这个怎么做么...

泛型. 方法一眼就能看到返回了啥类型.

一直刷着.

... 试试顺风车?

早日康复

震惊!! 除了处理器我竟然都没听过其他的 ==,