Redis笔记2 阻塞I/O、非阻塞I/O和I/O多路复用

setnx的分布式锁

使用Redis的 SETNX 命令可以实现分布式锁，下文介绍其实现方法。

SETNX命令简介

命令格式

SETNX key value

将 key 的值设为 value，当且仅当 key 不存在。 
若给定的 key 已经存在，则 SETNX 不做任何动作。 
SETNX 是SET if Not eXists的简写。

返回值

返回整数，具体为 
- 1，当 key 的值被设置 
- 0，当 key 的值没被设置

例子

redis> SETNX mykey “hello” 
(integer) 1 
redis> SETNX mykey “hello” 
(integer) 0 
redis> GET mykey 
“hello” 
redis>

使用SETNX实现分布式锁

多个进程执行以下Redis命令：

SETNX lock.foo <current Unix time + lock timeout + 1>

如果 SETNX 返回1，说明该进程获得锁，SETNX将键 lock.foo 的值设置为锁的超时时间（当前时间 + 锁的有效时间）。 
如果 SETNX 返回0，说明其他进程已经获得了锁，进程不能进入临界区。进程可以在一个循环中不断地尝试 SETNX 操作，以获得锁。

解决死锁

考虑一种情况，如果进程获得锁后，断开了与 Redis 的连接（可能是进程挂掉，或者网络中断），如果没有有效的释放锁的机制，那么其他进程都会处于一直等待的状态，即出现“死锁”。

上面在使用 SETNX 获得锁时，我们将键 lock.foo 的值设置为锁的有效时间，进程获得锁后，其他进程还会不断的检测锁是否已超时，如果超时，那么等待的进程也将有机会获得锁。

然而，锁超时时，我们不能简单地使用 DEL 命令删除键 lock.foo 以释放锁。考虑以下情况，进程P1已经首先获得了锁 lock.foo，然后进程P1挂掉了。进程P2，P3正在不断地检测锁是否已释放或者已超时，执行流程如下：

• P2和P3进程读取键 lock.foo 的值，检测锁是否已超时（通过比较当前时间和键 lock.foo 的值来判断是否超时）
• P2和P3进程发现锁 lock.foo 已超时
• P2执行 DEL lock.foo命令
• P2执行 SETNX lock.foo命令，并返回1，即P2获得锁
• P3执行 DEL lock.foo命令将P2刚刚设置的键 lock.foo 删除（这步是由于P3刚才已检测到锁已超时）
• P3执行 SETNX lock.foo命令，并返回1，即P3获得锁
• P2和P3同时获得了锁

从上面的情况可以得知，在检测到锁超时后，进程不能直接简单地执行 DEL 删除键的操作以获得锁。

为了解决上述算法可能出现的多个进程同时获得锁的问题，我们再来看以下的算法。 
我们同样假设进程P1已经首先获得了锁 lock.foo，然后进程P1挂掉了。接下来的情况：

• 进程P4执行 SETNX lock.foo 以尝试获取锁
• 由于进程P1已获得了锁，所以P4执行 SETNX lock.foo 返回0，即获取锁失败
• P4执行 GET lock.foo 来检测锁是否已超时，如果没超时，则等待一段时间，再次检测
• 如果P4检测到锁已超时，即当前的时间大于键 lock.foo 的值，P4会执行以下操作 
  GETSET lock.foo <current Unix timestamp + lock timeout + 1>
• 由于 GETSET 操作在设置键的值的同时，还会返回键的旧值，通过比较键 lock.foo 的旧值是否小于当前时间，可以判断进程是否已获得锁
• 假如另一个进程P5也检测到锁已超时，并在P4之前执行了 GETSET 操作，那么P4的 GETSET 操作返回的是一个大于当前时间的时间戳，这样P4就不会获得锁而继续等待。注意到，即使P4接下来将键 lock.foo 的值设置了比P5设置的更大的值也没影响。

另外，值得注意的是，在进程释放锁，即执行 DEL lock.foo 操作前，需要先判断锁是否已超时。如果锁已超时，那么锁可能已由其他进程获得，这时直接执行 DEL lock.foo 操作会导致把其他进程已获得的锁释放掉。

程序代码

用以下python代码来实现上述的使用 SETNX 命令作分布式锁的算法。

LOCK_TIMEOUT = 3
lock = 0
lock_timeout = 0
lock_key = 'lock.foo'
 
# 获取锁
while lock != 1:
    now = int(time.time())
    lock_timeout = now + LOCK_TIMEOUT + 1
    lock = redis_client.setnx(lock_key, lock_timeout)
    if lock == 1 or (now > int(redis_client.get(lock_key))) and now > int(redis_client.getset(lock_key, lock_timeout)):
        break
    else:
        time.sleep(0.001)
 
# 已获得锁
do_job()
 
# 释放锁
now = int(time.time())
if now < lock_timeout:
    redis_client.delete(lock_key)

 

Redis有序集合Zset的底层数据结构：跳跃表（跳表，skip list）

1 为什么引入跳跃表
我们知道红黑树是一种存在于内存中，可以保证在最坏的情况下，对红黑树进行例如search，insert，以及delete等基本的动态集合操作的时间复杂度为O(lg n)。

但是显而易见，红黑树实现起来比较复杂，尤其是对红黑树进行insert和delete操作。并且在红黑树中进行范围查询时需要对红黑树进行中序遍历，这也是比较复杂的操作。

那有没有一种能确保对动态集合search，insert以及delete等操作的时间复杂度在O(lg n)的前提下，实现比较简单，还能比较方便的进行范围查询的数据结构呢？

答案是肯定的，就是我们今天要总结的数据结构——跳跃表（skip list）。

2 引入的过程
例子：假设我们在内存中有一个长度达到10万以上的一个已经排好序的链表结构。我们要往这个链表结构中插入一个元素。我们是怎么进行插入的呢？

来看下图所示的这个列表（为了使链表结构简单，图中只画出了8个元素：1，4，5，7，8，9，12，15）：

 

 

 

上图所示链表中，各元素按照升序排列，现在要在该链表中插入元素10，首先要确定元素10应该插入的位置，如下图所示。

由于是链表结构因此无法使用二分查找算法，只能和原链表中的结点逐一比较大小来确定位置。这一步的时间复杂度是O(N)。

插入的过程到时很容易，直接改变结点指针的目标，时间复杂度是O(1)。

因此总体的时间复杂度是O(N)。

 

 

 

这对于拥有上十万的集合来说，这种办法显然太慢了。那有什么办法可以让search，insert以及delete操作性能更高一点呢？

search，insert以及delete操作其实归根结底就是search太慢的问题。所以只要search操作变快insert和delete操作也会变快。

让我们来回想一下MySQL索引。

所谓的索引就是把数据库表中的一些特定信息提取出来，缩小查询操作时的搜索范围，来提升查询性能。

那我们是不是可以借鉴数据库索引的思想，提取出链表中的部分关键结点。

还以上面的例子，那么我们可以取出所有值为奇数的结点作为关键结点。

 

 

 

此时如果要插入一个值为10的新节点，不再需要和原结点1，4，5，7，8，9，12逐一进行比较，只需要比较关键结点1，5，7，9，15即可。

 

 

 

确定了新结点在关键结点中的位置（9和15之间），就可以回到原链表，迅速定位到对应的位置插入（同样是9和15之间）。

 

 

 

 

 

节点数目少，优化效果不是很明显，如果是十万个结点，比较次数就整整减少了一半！也就是说虽然增加了50%的额外的空间，但是性能提高了一倍。

不过我们可以进一步思考。既然已经提取出了一层关键结点作为索引，那我们为何不能从索引中进一步提取，提出一层索引的索引？

 

 

 

有了2级索引之后，新的结点可以先和2级索引比较，确定大体范围之后在和1级索引进行比较，最后再回到原链表，找到并插入对应位置。

当结点很多的时候，比较次数就会减少到原来的四分之一！当节点足够多的时候，我们可以不止提出两层索引，还可以向更高层次提取，保证每一层是上一层结点数的一半。

提取的极限就是同一层只有两个结点的时候，因为一个结点没有比较的意义。这样的多层链表结构就是所谓的跳跃表。

3 跳跃表的基本概念
跳跃表是将链表改造支持二分法查找的数据结构 。

如果是一个单链表的话，他查找数据的时间复杂度为O(n)，于是给单链表添加一级索引每两个节点提取一个节点到上一级，我们把诌出来的哪一级叫做索引或者索引层，如下图：

 

 

 

当你查找12的时候，你只需要遍历6次就可以得到结果值 ，

先去第一层索引查到，遍历到9的时候发现下一个节点是15那我们就知道此时12就在这两个节点之间，所以我们进行down进入下一层

继续遍历这个时候我们只需要遍历两个节点就可以找到了，所以我们遍历12在建立上层索引的情况下是只需要遍历7次，但是单链表便利需要7次，那我们在继续添加及层索引如下图:

 

 

 

当有64个节点的链表的时候，则会创建多少层索引，通过计算会有5层，那么每一层的索引个数有 （n为总的索引树，k为创建的索引层数（不包括原始链表数据结构））,

最高的层的索引层的长度为2，那我们计算出 层级为 ，

如果我们每一层遍历M个元素那么我们的时间复杂度为 ,

我们的是两个元素结合为一个节点那么每一层最多遍历3个元素，那么我们时间复杂度为 那么时间复杂度为

现在就是在原有的得单链表上创建了多层索引而达到二分法查找，达到很高。

那么现在这样岂不是浪费了很多的内存（空间换用时间）。

有一个问题需要注意：

当大量的新节点通过逐层比较，最终插入到原链表之后，上层的索引结点会渐渐变得不够用。

这时候需要从新结点中选取一部分提到上一层。

可是究竟应该提拔谁呢？

这可能是随机选取（也叫抛硬币，50%的可能性会被提拔，50%的可能性不会被提拔）的，也可能是根据某些规则确定性的选取，其中随机选取更加常见（因为跳跃表的元素删除和添加是不可预测的，很难用一种有效的算法来保证跳跃表的索引分布始终均匀，随机选取虽然不能保证索引绝对均匀分布，却可以大体上趋于均匀）。

下面以随机选取为例进行说明，比如给定一个长度是7的有序链表，结点值一次是1，2，3，5，6，7，8。

那么我们可以取出所有值为奇数的结点作为关键结点。假如值为9的新节点插入原链表：

 

 

 

 

 

4 跳跃表的更新
4.1 跳跃表插入节点
具体看上面的分析，这里就不再一一赘述。

跳跃表插入节点的流程有以下几步：

• 新结点和各层索引结点逐一比较，确定原链表的插入位置，时间复杂度是O(logN)。
• 把索引插入到原链表，时间复杂度是O(1)。
• 利用抛硬币的随机方式，决定新结点是否提升到上一级索引。结果为正则提升，并且继续抛硬币，结果为负则停止，时间复杂度是O(logN)。

总体上，跳跃表插入操作的时间复杂度是O(logN)，而这种数据结构所占空间是2N。

4.2 跳跃表删除节点
跳跃表的删除操作比较简单，只要在索引层找到要删除的结点，然后顺藤摸瓜，删除每一层的相同结点即可。

这里还以一个长度是7的有序链表为例，结点值一次是1，2，3，5，6，7，8。取出所有值为奇数的结点作为关键结点。

如果某一层索引在删除后只剩下一个结点，那么整个一层就可以干掉了。例如要删除结点的值是5：

 

 

 

我们来总结一下跳跃表删除结点的操作步骤：

• 自上而下，查找第一次出现结点的索引，并逐层找到每一层对应的结点（因为每层索引都是由上层索引晋升的），时间复杂度是O(logN)。
• 删除每一层查找到的结点，如果该层只剩下一个结点，删除整个一层，时间复杂度是O(logN)。

总体上，跳跃表删除操作的时间复杂度是O(logN)。

从上面的总结可以看出，相对于红黑树来说，由于跳跃表维持结构平衡的成本比较低，完全依靠随机。而红黑树在多次插入和删除后，需要rebalance来重新调整结构平衡。
对于redis单线程的理解

https://zhuanlan.zhihu.com/p/128598311

 

 

https://www.icode9.com/content-2-688011.html

 

 

阻塞I/O、非阻塞I/O和I/O多路复用