关于给 DEL 添加扩展参数的设想

[ncghost1]

在 Redis 实现分布式锁时突然想到这个比较典型的问题：
首先用 Redis 做分布式锁的话，value 可以设置为每个客户端的id（client_id），如果出现了意外情况，即拿到锁后执行的机子卡住了，没有给锁续命导致key超时了，之后锁被第二个 cilent 拿到。那么接下来就可能会导致第一个 client 接着执行完之后，把第二个 cilent 设置的key 删掉，接连下去可能导致锁一直失效了。所以我们删除 key 的时候要判断 key 的 value 是否等于自身的 client_id，比如：

// 伪代码
if (client_id == RedisGet(lockKey)) {
    RedisDel(lockKey)
}

那么这个还是会有个问题，就是 if 判断正确之后又卡住了导致锁超时，那么接下来这个进程会把别的进程设置的 key 又删除了。所以这段代码需要保证原子性，可以使用lua脚本来完成。
虽然确实是可以使用lua脚本来完成，像 set 没有扩展参数时也是这么做的，但是之后还是把这些能用lua脚本完成的事放到了 set 的扩展参数里来更方便使用，所以我在想是否也可以给 del 提供扩展参数呢？🙃 或者我认为可以多加一些del命令，比如delValueIs [key] [value]
@enjoy-binbin 你印象里有人曾提出这个事情吗？

[enjoy-binbin]

其实就是 CAS / CAD，这个一直都有提过，只是社区现在一直没有推这个，理由是：

1. 这两个功能可以用很简单的 lua 去实现或者 module
2. CAS/CAD 中的 C，传输和比较大字符串的成本比较大

不过我感觉这个在 7.2 可能可以加进去，因为很多 member 都想加包括我（不确定 core-team 的规划，要看后面 7.2 的规划，找机会我也去问问）
我记得的话 CAD 最近的一次 issue 讨论是在 redis/redis#10345 and CAS 是在 redis/redis#8361
PS: del 提供不了扩展参数，它并不是只针对字符串，CAS 可以加到 SET 里，CAD 估计要一个新命令

[ncghost1]

原来也一直在讨论啦，查了一下没查到估计刚刚是我搜索不对，谢谢解答～

[ncghost1]

RedissonReadLock链接
@enjoy-binbin 话说彬哥看过Redisson用Redis实现的分布式锁吗？为什么可以在只有一个写锁的时候还能加读锁？ (mode == 'write' and redis.call('hexists', KEYS[1], ARGV[3]) == 1)这东西已经迷惑了我一晚上了QWQ

 <T> RFuture<T> tryLockInnerAsync(long waitTime, long leaseTime, TimeUnit unit, long threadId, RedisStrictCommand<T> command) {
        return evalWriteAsync(getRawName(), LongCodec.INSTANCE, command,
                                "local mode = redis.call('hget', KEYS[1], 'mode'); " +
                                "if (mode == false) then " +
                                  "redis.call('hset', KEYS[1], 'mode', 'read'); " +
                                  "redis.call('hset', KEYS[1], ARGV[2], 1); " +
                                  "redis.call('set', KEYS[2] .. ':1', 1); " +
                                  "redis.call('pexpire', KEYS[2] .. ':1', ARGV[1]); " +
                                  "redis.call('pexpire', KEYS[1], ARGV[1]); " +
                                  "return nil; " +
                                "end; " +
                                "if (mode == 'read') or (mode == 'write' and redis.call('hexists', KEYS[1], ARGV[3]) == 1) then " +
                                  "local ind = redis.call('hincrby', KEYS[1], ARGV[2], 1); " + 
                                  "local key = KEYS[2] .. ':' .. ind;" +
                                  "redis.call('set', key, 1); " +
                                  "redis.call('pexpire', key, ARGV[1]); " +
                                  "local remainTime = redis.call('pttl', KEYS[1]); " +
                                  "redis.call('pexpire', KEYS[1], math.max(remainTime, ARGV[1])); " +
                                  "return nil; " +
                                "end;" +
                                "return redis.call('pttl', KEYS[1]);",
                        Arrays.<Object>asList(getRawName(), getReadWriteTimeoutNamePrefix(threadId)),
                        unit.toMillis(leaseTime), getLockName(threadId), getWriteLockName(threadId));
    }

[ncghost1]

写锁存在，为什么还要重入读锁？写和读都同时加锁不是会冲突吗？

[ncghost1]

还有因为我没有分布式条件不是很懂关于主从、集群之类的命令，有没有什么命令或者办法可以得知到从节点是否已经完成新命令的同步？
因为一个典型的 redis 锁失效的情况就是没有异步同步到从节点宕机了，从节点没有保存这个锁，导致会被重复加锁。由 Redlock 和 Zookeeper 一类的需要超过半数以上节点”收到通知“后才认为加锁成功的分布式锁策略想到的方法，可以在从节点全部同步好设置锁的命令后才认为加锁成功。从节点一般用来备份数量也不多（两个左右？），感觉让从节点同步完这个设置锁命令应该一般要比 Redlock 到半数以上的主节点设置完key要快一些。而且 Redlock 依然会有这个 failover 导致丢锁的问题，如果正好差这一个节点即可让另一个客户端加上锁又依然会因为 failover 出事。但是如果判断获取锁成功的依据是主节点与全部从节点都设置了锁的话，即使 failover 也不会丢锁。🤔

[enjoy-binbin]

有个wait命令

[enjoy-binbin]

写锁存在，为什么还要重入读锁？写和读都同时加锁不是会冲突吗？

没仔细研究过那个（不是 Javaer...）我自己大概的猜测是说想提高并发？类似读写不冲突，有写锁但是不影响读
例如递归我自己调用自己，要加写锁的时候就正常加（并且写锁可重入），然后在后面的某一处按照业务逻辑需要 read lock，然后就走了 read 的逻辑
看着代码大概猜的，后面研究出来也可以跟我讲下哈哈哈

[ncghost1]

我打算造个昨天说的，如果有从节点存在则所有从节点同步完全才能认为获取到锁的Redis分布式锁轮子，暂时取名叫ReplicaLock😀？我认为可以在普通的使用 redis 分布式锁基础上消除未同步到从节点的宕机带来的锁失效（如果有从的话），但是我不了解主从同步的速度够不够快，要是主从同步不如到半数节点以上加锁（Redlock）的速度就尴尬了，如果够快的话将是比普通的到一个redis节点加锁用法要更安全，但性能稍低一些的分布式锁用法。您认为可行吗🤣？
edited：咦，好像没有获取从节点数量的命令吗？

[enjoy-binbin]

要造的话当然是都可以，不过我自己想法是，本身做 lock 速度就是要快，我印象中大家一般都用单节点用来做 lock，就不会说特意为一个 lock 做主从/集群啥的
这种同步复制你还得考虑一下，假如有一个从节点有问题，例如它一直无法被主库连上（主从延迟）或者从库读慢查询被阻塞（如果不是单独只用做锁的话）

》 好像没有获取从节点数量的命令吗
我印象中也是没有，数量是从 INFO 命令里获取的，或者哨兵那边也有命令能获取

[ncghost1]

主从延迟感觉应该算是选用这种方案的一个新问题，且不好解决。从库只用来备份才建议使用。
只有info可以查看的话，看来有点麻烦，还要字符串匹配去取值……
话说使用写命令然后 wait ，如果返回了从节点数量的数值就一定能保证它们都写入了吗？我在想会不会有数据丢失啥的。要是有能从主节点发起所有slave touch的命令，返回成功的数量来检查是否所有从节点都有key就好了。🧐

[ncghost1]

突然想到可不可以提个返回从节点数的命令需求，因为一般都是用代码来操作redis的而不是看着它的 client，从info里去取还要做字符串匹配，字符串转数字实在是太麻烦了，还增加了时间消耗...而且没有一个获取从节点数的命令，执行wait命令又要输入从节点数，在代码上真不好弄，我个人认为太搞了...
已经试着提了一下下~ issue10852因为没有这个命令的话这锁没法造了QWQ