redis实现分布式锁用哪些命令（Redis常见的使用场景概括-进阶篇）

上一篇介绍了Redis基本的使用场景，今天介绍在高并发的场景中，常用到的一种技术手段，那就是锁机制。

跟其他锁一样，Redis的锁根据锁机制的不同分为乐观锁和悲观锁，经常被用于防止出现雪崩效应。下面分别先简单介绍一下。

通常基于版本记录机制实现，不是我们今天要详细介绍的，我们拿个例子简单说明一下，假定有A和B两个事务同时执行：

第一步：A读取数据，记录数据当前版本号n（相信没有人会动我将要改的数据，真乐观是不是，哈哈）；

第二步：B修改数据，此时版本号变为n 1；

第三步：A要改数据了，看了下版本号，跟刚才对不上啊（事务失败了）；

过程说明：

B事务

A事务

结论：当如果监视的key在watch后发生过变化，则返回失败。

这就是乐观锁，适合于读多写少并的场景。

这个很好理解，A每次修改数据之前都会加上锁，防止被其他事务修改（真够悲伤的）。今天重点介绍的就是这货了。

例子

首页某个页面访问量大，所以加了缓存，并设定缓存过期后刷新，如果只是这样处理，那么会有什么问题？问题是当请求并发量很大的时候，缓存过期的瞬间，大量请求会穿透缓存直达数据库，造成雪崩效应，数据库服务器直接宕机。如果有锁机制，便可以控制只有单个请求去更新缓存，更新未完成前，其他请求依旧读取旧缓存。下面给出实现的过程：

先来看一段代码实现：

版本1

这逻辑很简单，但是如果请求执行过程意外退出了，没有删除锁，那么以后缓存都不会更新了。

嗯，很好，知道问题所在，我优化一下，给它个过期时间不就行了：

版本2

那么这样就没有问题了吗，当然没这么简单了，虽然我们保证只有一个setnx成功，但是expire可以一直刷新啊，导致锁一直有效。

还好Redis的作者antirez很早就考虑到这问题了，从Redis 2.6.12版本起，set涵盖了setnx的功能，并且set本身已经包含了设置过期时间的功能。那么我们的实现变得简单了：

版本3

这样就行了吗？

也还不行，如果更新时间比锁的有效期还长，如果不加以判断直接删除锁，那么就会出现误删其他锁的情况，针对这种情况，我们再优化一下，变成：

版本4

这下完美了吗，依然没有。试想一下，如果del锁的请求到达过程中出现网络延迟会依旧会误删其他锁。

也许你会问有没有靠谱点的实现，答案是没有。这个问题正是基于单Redis节点的分布式锁的局限性所在，即便如此，只要实现分布式锁的时候加以注意，它依然相当有用。

假如要实现多节点的分布式锁，有没有办法呢？有的，因为Redis的作者antirez大神已经给出一个更好的实现 - Redlock算法。有兴趣的读者可以Redis官网上了解一番，当然了，前提是你已经理解了基于单Redis节点的分布式锁是如何实现的。

ps：之后会有MySQL优化系列文章发表，敬请期待！