排版好烦,怎么排版啊!

  上一篇写的是基础内容,这篇开始进入正题。

  redis最基础的运用之一就是分布式锁,我之前所理解的分布式锁和常规的多线程中的锁机制是一样的(为了保证共享数据的可靠性,不至于出现一种混沌状态),这篇作者就详细解释,并用代码示例解释了一遍什么是分布式锁。

  开篇作者也简单介绍了一下原子操作,何谓原子操作,来自wiki的解释为:所谓原子操作是指不会被线程调度机制打断的操作;这种操作一旦开始,就一直运行到结束,中间不会有任何 context switch 线程切换。由于并发的时候对数据的读写并不是原子的,因此就会导致数据出现混沌状态,很显然这是不行的,接下来就是如何解决这个问题的过程。

  由于作者解释的setnx让我觉得云里雾里,我从其他地方查询之后去到官方的文档(setsetnx)说明,可能加载比较感人,因此我做了一下搬运和翻译(凑合看,英语渣)(翻译完了才发现上一篇说的文档里有,不过没更新到6.0)

  分布式锁的实现就是官方对set功能的一次拓展,具体使用的方式就是官方对于set命令的pattern中的 SET resource-name anystring NX EX max-lock-time (可以看一下我翻译的那篇),在该拓展实现之前为了实现分布式锁是非常复杂的,原因是setnx和expire是两条指令而不是一条(意思就是在两条指令执行过程中间可能导致锁的不正确acquire或者release)。

分布式锁面临的问题

  超时问题

    该问题产生的原因在于任务执行的时间可能会长于设置锁时的timeout时间。作者举的例子是,第一个线程执行完成之前锁已经超时,这就导致第二个线程成功acquire了这把锁,但是在第二个线程acquire了锁之后,第一个线程的任务终于完成了,将锁release了,这个时候第三个线程就能够acquire这把锁。这就是分布式锁的超时问题。

    为了解决这个问题,作者提出了两种方案,第一种就是不要将分布式锁用于执行时间较长的任务,第二种是为set指令的value设置一个参数,在需要release锁的时候先匹配该参数是否一致,如果一致那么再release这把锁。显而易见的,第二种方案是更好的解决方案,但是很容易就能察觉到第二种方案和在拓展set指令之前一样,需要执行两个命令才能完成这个流程,可能这中间就出现了什么乱七八糟的问题,针对这个问题,作者留下了一个lua脚本~,因为lua脚本能够保证多个原子性操作的连续执行。脚本内容如下:

# delifequals
if redis.call("get",KEYS[1]) == ARGV[1] then
 return redis.call("del",KEYS[1])
else
 return 0
end

  可重入性

    可重入性就是一个线程能够在持有锁的情况下请求加锁,那么这个锁就是可重入的。比如 Java 语言里有个 ReentrantLock 就是可重入锁(python中的RLock、local)。作者在文中明确表示不推荐使用可重入锁,因为实现起来需要考虑很多东西,导致非常复杂,并且表示完全可以不适用到可重入锁(python中的RLock还会降低性能)。这部分代码我就不附上了,感兴趣的可以找一下。