wu版-天下无难试之Redis面试题刁难大全

面试中可能会被问到的Redis问题整理，希望能汇总各种奇葩问题，帮助更多的人思考学习。大多非作者原创，只是收集整理而来。

Redis在互联网技术存储方面使用如此广泛，几乎所有的后端技术面试官都要在Redis的使用和原理方面对小伙伴们进行各种刁难。作为一名在互联网技术行业打击过成百上千名【请允许我夸张一下】的资深技术面试官，看过了无数落寞的身影失望的离开，略感愧疚，故献上此文，希望各位读者以后面试势如破竹，永无失败！

=========================此部分为常见问题相信会大力帮到你===========================

这一部分一般是会在你的项目中提交，面试官很容易揪着一直问，所以一定要有深度。可以抓取一个点收集一系列的相关问题，我在这里后续也会进行添加。

Redis有哪些数据结构？

字符串String、字典Hash、列表List、集合Set、有序集合SortedSet。

如果你是Redis中高级用户，还需要加上下面几种数据结构HyperLogLog、Geo、Pub/Sub。

如果你说还玩过Redis Module，像BloomFilter，RedisSearch，Redis-ML，面试官得眼睛就开始发亮了。

使用过Redis分布式锁么，它是什么回事？

先拿setnx来争抢锁，抢到之后，再用expire给锁加一个过期时间防止锁忘记了释放。

这时候对方会告诉你说你回答得不错，然后接着问如果在setnx之后执行expire之前进程意外crash或者要重启维护了，那会怎么样？

这时候你要给予惊讶的反馈：唉，是喔，这个锁就永远得不到释放了。紧接着你需要抓一抓自己得脑袋，故作思考片刻，好像接下来的结果是你主动思考出来的，然后回答：我记得set指令有非常复杂的参数，这个应该是可以同时把setnx和expire合成一条指令来用的！对方这时会显露笑容，心里开始默念：摁，这小子还不错。

假如Redis里面有1亿个key，其中有10w个key是以某个固定的已知的前缀开头的，如果将它们全部找出来？

使用keys指令可以扫出指定模式的key列表。

对方接着追问：如果这个redis正在给线上的业务提供服务，那使用keys指令会有什么问题？

这个时候你要回答redis关键的一个特性：redis的单线程的。keys指令会导致线程阻塞一段时间，线上服务会停顿，直到指令执行完毕，服务才能恢复。这个时候可以使用scan指令，scan指令可以无阻塞的提取出指定模式的key列表，但是会有一定的重复概率，在客户端做一次去重就可以了，但是整体所花费的时间会比直接用keys指令长。

使用过Redis做异步队列么，你是怎么用的？

一般使用list结构作为队列，rpush生产消息，lpop消费消息。当lpop没有消息的时候，要适当sleep一会再重试。

如果对方追问可不可以不用sleep呢？list还有个指令叫blpop，在没有消息的时候，它会阻塞住直到消息到来。

如果对方追问能不能生产一次消费多次呢？使用pub/sub主题订阅者模式，可以实现1:N的消息队列。

如果对方追问pub/sub有什么缺点？在消费者下线的情况下，生产的消息会丢失，得使用专业的消息队列如rabbitmq等。

如果对方追问redis如何实现延时队列？我估计现在你很想把面试官一棒打死如果你手上有一根棒球棍的话，怎么问的这么详细。但是你很克制，然后神态自若的回答道：使用sortedset，拿时间戳作为score，消息内容作为key调用zadd来生产消息，消费者用zrangebyscore指令获取N秒之前的数据轮询进行处理。

到这里，面试官暗地里已经对你竖起了大拇指。但是他不知道的是此刻你却竖起了中指，在椅子背后。

如果有大量的key需要设置同一时间过期，一般需要注意什么？

如果大量的key过期时间设置的过于集中，到过期的那个时间点，redis可能会出现短暂的卡顿现象。一般需要在时间上加一个随机值，使得过期时间分散一些。

Redis如何做持久化的？

bgsave做镜像全量持久化，aof做增量持久化。因为bgsave会耗费较长时间，不够实时，在停机的时候会导致大量丢失数据，所以需要aof来配合使用。在redis实例重启时，会使用bgsave持久化文件重新构建内存，再使用aof重放近期的操作指令来实现完整恢复重启之前的状态。

对方追问那如果突然机器掉电会怎样？取决于aof日志sync属性的配置，如果不要求性能，在每条写指令时都sync一下磁盘，就不会丢失数据。但是在高性能的要求下每次都sync是不现实的，一般都使用定时sync，比如1s1次，这个时候最多就会丢失1s的数据。

对方追问bgsave的原理是什么？你给出两个词汇就可以了，fork和cow。fork是指redis通过创建子进程来进行bgsave操作，cow指的是copy on write，子进程创建后，父子进程共享数据段，父进程继续提供读写服务，写脏的页面数据会逐渐和子进程分离开来。

Pipeline有什么好处，为什么要用pipeline？

可以将多次IO往返的时间缩减为一次，前提是pipeline执行的指令之间没有因果相关性。使用redis-benchmark进行压测的时候可以发现影响redis的QPS峰值的一个重要因素是pipeline批次指令的数目。

Redis的同步机制了解么？

Redis可以使用主从同步，从从同步。第一次同步时，主节点做一次bgsave，并同时将后续修改操作记录到内存buffer，待完成后将rdb文件全量同步到复制节点，复制节点接受完成后将rdb镜像加载到内存。加载完成后，再通知主节点将期间修改的操作记录同步到复制节点进行重放就完成了同步过程。

是否使用过Redis集群，集群的原理是什么？

Redis Sentinal着眼于高可用，在master宕机时会自动将slave提升为master，继续提供服务。

Redis Cluster着眼于扩展性，在单个redis内存不足时，使用Cluster进行分片存储。

======================出现概率不如上面（了解）=====================================

mySQL里有2000w数据，redis中只存20w的数据，如何保证redis中的数据都是热点数据

相关知识：redis 内存数据集大小上升到一定大小的时候，就会施行数据淘汰策略。redis 提供 6种数据淘汰策略：

 volatile-lru：从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰

volatile-ttl：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰

volatile-random：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰

allkeys-lru：从数据集（server.db[i].dict）中挑选最近最少使用的数据淘汰

allkeys-random：从数据集（server.db[i].dict）中任意选择数据淘汰

no-enviction（驱逐）：禁止驱逐数据

Memcache与Redis的区别都有哪些？

 1)、存储方式

 Memecache把数据全部存在内存之中，断电后会挂掉，数据不能超过内存大小。

Redis有部份存在硬盘上，这样能保证数据的持久性。

2)、数据支持类型

 Memcache对数据类型支持相对简单。

Redis有复杂的数据类型。

3)、使用底层模型不同

 它们之间底层实现方式 以及与客户端之间通信的应用协议不一样。

Redis直接自己构建了VM 机制 ，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求。

Redis 常见的性能问题都有哪些？如何解决？

 1).Master写内存快照，save命令调度rdbSave函数，会阻塞主线程的工作，当快照比较大时对性能影响是非常大的，会间断性暂停服务，所以Master最好不要写内存快照。

2).Master AOF持久化，如果不重写AOF文件，这个持久化方式对性能的影响是最小的，但是AOF文件会不断增大，AOF文件过大会影响Master重启的恢复速度。Master最好不要做任何持久化工作，包括内存快照和AOF日志文件，特别是不要启用内存快照做持久化,如果数据比较关键，某个Slave开启AOF备份数据，策略为每秒同步一次。

3).Master调用BGREWRITEAOF重写AOF文件，AOF在重写的时候会占大量的CPU和内存资源，导致服务load过高，出现短暂服务暂停现象。

4). Redis主从复制的性能问题，为了主从复制的速度和连接的稳定性，Slave和Master最好在同一个局域网内

=========================此为别人的遇到的面试题（反应出面试时的一种常态）=================

关于 Redis 队列的一道面试题

面试的时候讲到自己做的一个项目，我说用了 Redis 队列， lpush 进， rpop 出，面试官打断问：一般入队列没有问题，如果出现对列阻塞了怎么办？实际生产环境中在这里没有出现问题，而且队列量很大，我没有太理解面试官问的什么。（消费者挂掉 or 太慢。怎么处理）

Redis 作队列需要注意什么问题？如果是高并发情况下怎么办？谢谢大家指点！

还问有没有考虑队列的长度呢，我在实际开发中，没有考虑过这个问题， redis 可以一直入队列吧，不过如果队列太大，有可能占满内存，那这种情况怎么办？

1 、队列阻塞问题做好报警  2 、从业务方面考虑能够动态调控提高队列处理能力

8 iyaozhen   2016-03-08 16:17:17 +08:00   ♥ 2 最近就遇到这个问题了。  消费者的速度没有生产者快，增加消费者也缓解不了， Redis 会被打满，直到挂掉（影响其它业务功能）。而且 Redis 目前的数据清理策略是根据 key 的，如果设置了清理用作队列的那个 list key 会被清掉，如果这是业务代码写的不是太好的话消费者和生产者都会挂掉。消费者最好还是异步消费，不要阻塞队列。  当然还是要对队列长度做监控。  目前已经转投 Kafka 了。  额，可能说的不是太专业。看具体业务吧，你拿到数据肯定是需要做一些处理，这个过程可以异步操作，比如异步写文件，异步入库等。甚至继续向下游业务抛，压力往后转移。     额，可能说的不是太专业。看具体业务吧，你拿到数据肯定是需要做一些处理，这个过程可以异步操作，比如异步写文件，异步入库等。甚至继续向下游业务抛，压力往后转移。

8 iyaozhen   2016-03-08 16:17:17 +08:00   ♥ 2 最近就遇到这个问题了。  消费者的速度没有生产者快，增加消费者也缓解不了， Redis 会被打满，直到挂掉（影响其它业务功能）。而且 Redis 目前的数据清理策略是根据 key 的，如果设置了清理用作队列的那个 list key 会被清掉，如果这是业务代码写的不是太好的话消费者和生产者都会挂掉。消费者最好还是异步消费，不要阻塞队列。  当然还是要对队列长度做监控。  目前已经转投 Kafka 了。 出队列阻塞就是消费者的处理速度跟不上生产者产生的任务，加消费者提高处理速度。  消费者加到极限还处理不过来，实在有爆内存的风险的时候，可以考虑将任务数据持久化，避免数据丢失，先把任务状态保存下来，根据具体业务做优化调整，等待异常问题解决之后再继续处理。

关于你的问题我遇见过：  1. Redis 关于内存满了如何处理的策略要配置好，是使用 lru 还是 noviction 等，一定要想清楚， Redis 可使用的内存大小要配置适当，最好是你 Redis 内存使用峰值的几倍甚至 10 倍。  2. Redis 内存要做好报警，简单的做法是每分钟或更短的时间使用 info 指令获取内存使用情况，如果超过某个值要马上想办法处理。  3. 如果能多加 consumer ，就尝试多加 consumer 解决。  4. 如果还没有解决，你可能需要想办法提升 Redis 内存占用，可能想办法平行扩展 Redis Server 。  5. 如果还没有解决，就只能想办法用 kafka 这种可以持久化的方式了，或者你自己设计一种 Redis 的持久化方式，因为内存总归是有限的且稀缺的。

按我的理解, 是说 " consumer 吞吐量太弱, 不及 producer 生产速度, 此时何解? "  这就难玩儿了. . 就好比要解决北上广住房问题 .  不考虑移民 (投靠其他技术选型),  1. 监控队列, 动态调配 consumer, 适时增加 consumer  最简单有效的办法, 从根本上解决问题. 当然你得花钱加机器  2. 做好降级方案, 达到预设阀值, 出队后暂不处理, 直接先持久化再说  3. consumer 投递异步任务, 不要阻塞出队列  这个比较难玩儿

============================一些基础相关的东东================================

redis的并发竞争问题如何解决?

Redis为单进程单线程模式，采用队列模式将并发访问变为串行访问。Redis本身没有锁的概念，Redis对于多个客户端连接并不存在竞争，但是在Jedis客户端对Redis进行并发访问时会发生连接超时、数据转换错误、阻塞、客户端关闭连接等问题，这些问题均是由于客户端连接混乱造成。对此有2种解决方法：

1.客户端角度，为保证每个客户端间正常有序与Redis进行通信，对连接进行池化，同时对客户端读写Redis操作采用内部锁synchronized。

2.服务器角度，利用setnx实现锁。

　　对于第一种，需要应用程序自己处理资源的同步，可以使用的方法比较通俗，可以使用synchronized也可以使用lock；第二种需要用到Redis的setnx命令，但是需要注意一些问题。

redis事物的了解CAS(check-and-set 操作实现乐观锁 )?

　　和众多其它数据库一样，Redis作为NoSQL数据库也同样提供了事务机制。在Redis中，MULTI/EXEC/DISCARD/WATCH这四个命令是我们实现事务的基石。相信对有关系型数据库开发经验的开发者而言这一概念并不陌生，即便如此，我们还是会简要的列出Redis中事务的实现特征：

1). 在事务中的所有命令都将会被串行化的顺序执行，事务执行期间，Redis不会再为其它客户端的请求提供任何服务，从而保证了事物中的所有命令被原子的执行。

2). 和关系型数据库中的事务相比，在Redis事务中如果有某一条命令执行失败，其后的命令仍然会被继续执行。

3). 我们可以通过MULTI命令开启一个事务，有关系型数据库开发经验的人可以将其理解为"BEGIN TRANSACTION"语句。在该语句之后执行的命令都将被视为事务之内的操作，最后我们可以通过执行EXEC/DISCARD命令来提交/回滚该事务内的所有操作。这两个Redis命令可被视为等同于关系型数据库中的COMMIT/ROLLBACK语句。

4). 在事务开启之前，如果客户端与服务器之间出现通讯故障并导致网络断开，其后所有待执行的语句都将不会被服务器执行。然而如果网络中断事件是发生在客户端执行EXEC命令之后，那么该事务中的所有命令都会被服务器执行。

5). 当使用Append-Only模式时，Redis会通过调用系统函数write将该事务内的所有写操作在本次调用中全部写入磁盘。然而如果在写入的过程中出现系统崩溃，如电源故障导致的宕机，那么此时也许只有部分数据被写入到磁盘，而另外一部分数据却已经丢失。Redis服务器会在重新启动时执行一系列必要的一致性检测，一旦发现类似问题，就会立即退出并给出相应的错误提示。此时，我们就要充分利用Redis工具包中提供的redis-check-aof工具，该工具可以帮助我们定位到数据不一致的错误，并将已经写入的部分数据进行回滚。修复之后我们就可以再次重新启动Redis服务器了。

.WATCH命令和基于CAS的乐观锁：

　　在Redis的事务中，WATCH命令可用于提供CAS(check-and-set)功能。假设我们通过WATCH命令在事务执行之前监控了多个Keys，倘若在WATCH之后有任何Key的值发生了变化，EXEC命令执行的事务都将被放弃，同时返回Null multi-bulk应答以通知调用者事务执行失败。例如，我们再次假设Redis中并未提供incr命令来完成键值的原子性递增，如果要实现该功能，我们只能自行编写相应的代码。其伪码如下：

val = GET mykey

val = val + 1

SET mykey $val

　　以上代码只有在单连接的情况下才可以保证执行结果是正确的，因为如果在同一时刻有多个客户端在同时执行该段代码，那么就会出现多线程程序中经常出现的一种错误场景--竞态争用(race condition)。比如，客户端A和B都在同一时刻读取了mykey的原有值，假设该值为10，此后两个客户端又均将该值加一后set回Redis服务器，这样就会导致mykey的结果为11，而不是我们认为的12。为了解决类似的问题，我们需要借助WATCH命令的帮助，见如下代码：

WATCH mykey

val = GET mykey

val = val + 1

MULTI

SET mykey $val

EXEC

　　和此前代码不同的是，新代码在获取mykey的值之前先通过WATCH命令监控了该键，此后又将set命令包围在事务中，这样就可以有效的保证每个连接在执行EXEC之前，如果当前连接获取的mykey的值被其它连接的客户端修改，那么当前连接的EXEC命令将执行失败。这样调用者在判断返回值后就可以获悉val是否被重新设置成功。

redis持久化的几种方式

1、快照（snapshots）

缺省情况情况下，Redis把数据快照存放在磁盘上的二进制文件中，文件名为dump.rdb。你可以配置Redis的持久化策略，例如数据集中每N秒钟有超过M次更新，就将数据写入磁盘；或者你可以手工调用命令SAVE或BGSAVE。

工作原理

　　． Redis forks.

　　． 子进程开始将数据写到临时RDB文件中。

　　． 当子进程完成写RDB文件，用新文件替换老文件。

　　． 这种方式可以使Redis使用copy-on-write技术。

2、AOF

快照模式并不十分健壮，当系统停止，或者无意中Redis被kill掉，最后写入Redis的数据就会丢失。这对某些应用也许不是大问题，但对于要求高可靠性的应用来说，

Redis就不是一个合适的选择。

Append-only文件模式是另一种选择。

你可以在配置文件中打开AOF模式

3、虚拟内存方式

4、diskstore方式

redis的缓存失效策略和主键失效机制

　　作为缓存系统都要定期清理无效数据，就需要一个主键失效和淘汰策略.

　　在Redis当中，有生存期的key被称为volatile。在创建缓存时，要为给定的key设置生存期，当key过期的时候（生存期为0），它可能会被删除。

1、影响生存时间的一些操作

　　生存时间可以通过使用 DEL 命令来删除整个 key 来移除，或者被 SET 和 GETSET 命令覆盖原来的数据，也就是说，修改key对应的value和使用另外相同的key和value来覆盖以后，当前数据的生存时间不同。

　　比如说，对一个 key 执行INCR命令，对一个列表进行LPUSH命令，或者对一个哈希表执行HSET命令，这类操作都不会修改 key 本身的生存时间。另一方面，如果使用RENAME对一个 key 进行改名，那么改名后的 key 的生存时间和改名前一样。

RENAME命令的另一种可能是，尝试将一个带生存时间的 key 改名成另一个带生存时间的 another_key ，这时旧的 another_key (以及它的生存时间)会被删除，然后旧的 key 会改名为 another_key ，因此，新的 another_key 的生存时间也和原本的 key 一样。使用PERSIST命令可以在不删除 key 的情况下，移除 key 的生存时间，让 key 重新成为一个persistent key 。

=================================================================================================================================

分布式的环境下， MySQL和Redis如何保持数据的一致性？

作者：liu kelin 链接：https://www.zhihu.com/question/36413559/answer/71303343 来源：知乎 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。 说个大概吧，我们热数据基本都是redis，增删改都是操作mysql，对于读是保存到redis，这样就涉及到数据同步操作，同步操作分为两大块，我们的叫法是，一个是全量(将全部数据一次写入到redis，时间几小时不等)，一个是增量（实时更新）。这里说的是增量，主要问题是即时性，因为增删改都是直接操作mysql变更都在MySQL（这里高并发的问题是用分库分表加外层的负载均衡） 所以我们的方向是读取binlog然后分析 ，利用消息推送到某服务器A，再进行分析，然后更新各台redis，消息推送工具用的是rabbitMQ，可设定某表的变更推送(分三类update insert delate 包含变更前后的数据)，这里有个问题是：mysql数据操作太频繁产生的推送可能会很多，所以分析处理脚本处理速度一定要跟得上（我用Python写，前期多线程（坑），后来改成多进程），还有一个问题是，对于mysql-redis的数据关系映射设定不要太复杂，一表对一表就行，数据组合交给业务层做，这样分析处理脚本不会太多负担，处理速度更快，而且操作redis也更简单，redis每个对应mysql数据表的可使用多端口多实例，redis是单线程而且这样对于redis的主从和负载均衡有利， 题外话：对于服务器A 可以再给其它服务做一个数据表增量变更数据获取接口，利用数据纬度，获取时间段的变更数据。 追加，对于订单类部分，都是完全使用mysql，这个做好数据服务器，DB，table，分区，的拆分就好了，看并发请求越多拆分越多。 上面说太多都是屁话，其实就是MySQL binlog增量订阅消费+消息队列+处理并把数据更新到redis 一个简单的例子。 https://github.com/liukelin/canal_mysql_nosql_sync

数据一致性的问题《Improving cache consistency》里有详细的谈论，最终的方案跟 @liu kelin 的一致：读Redis，写MySQL，同时消费MySQL binlog更新Redis。

Redis并发问题

Redis为单进程单线程模式，采用队列模式将并发访问变为串行访问。Redis本身没有锁的概念，Redis对于多个客户端连接并不存在竞争，但是在Jedis客户端对Redis进行并发访问时会发生连接超时、数据转换错误、阻塞、客户端关闭连接等问题，这些问题均是由于客户端连接混乱造成。对此有2种解决方法： 1.客户端角度，为保证每个客户端间正常有序与Redis进行通信，对连接进行池化，同时对客户端读写Redis操作采用内部锁synchronized。 2.服务器角度，利用setnx实现锁。 对于第一种，需要应用程序自己处理资源的同步，可以使用的方法比较通俗，可以使用synchronized也可以使用lock；第二种需要用到Redis的setnx命令，但是需要注意一些问题。 SETNX命令（SET if Not eXists） 语法： SETNX key value 功能： 将 key 的值设为 value ，当且仅当 key 不存在；若给定的 key 已经存在，则 SETNX 不做任何动作。 时间复杂度： O(1) 返回值： 设置成功，返回 1 。 设置失败，返回 0 。 模式：将 SETNX 用于加锁(locking) SETNX 可以用作加锁原语(locking primitive)。比如说，要对关键字(key) foo 加锁，客户端可以尝试以下方式： SETNX lock.foo <current Unix time + lock timeout + 1> 如果 SETNX 返回 1 ，说明客户端已经获得了锁， key 设置的unix时间则指定了锁失效的时间。之后客户端可以通过 DEL lock.foo 来释放锁。 如果 SETNX 返回 0 ，说明 key 已经被其他客户端上锁了。如果锁是非阻塞(non blocking lock)的，我们可以选择返回调用，或者进入一个重试循环，直到成功获得锁或重试超时(timeout)。 但是已经证实仅仅使用SETNX加锁带有竞争条件，在特定的情况下会造成错误。 处理死锁(deadlock) 上面的锁算法有一个问题：如果因为客户端失败、崩溃或其他原因导致没有办法释放锁的话，怎么办？ 这种状况可以通过检测发现——因为上锁的 key 保存的是 unix 时间戳，假如 key 值的时间戳小于当前的时间戳，表示锁已经不再有效。 但是，当有多个客户端同时检测一个锁是否过期并尝试释放它的时候，我们不能简单粗暴地删除死锁的 key ，再用 SETNX 上锁，因为这时竞争条件(race condition)已经形成了： C1 和 C2 读取 lock.foo 并检查时间戳， SETNX 都返回 0 ，因为它已经被 C3 锁上了，但 C3 在上锁之后就崩溃(crashed)了。 C1 向 lock.foo 发送 DEL 命令。 C1 向 lock.foo 发送 SETNX 并成功。 C2 向 lock.foo 发送 DEL 命令。 C2 向 lock.foo 发送 SETNX 并成功。 出错：因为竞争条件的关系，C1 和 C2 两个都获得了锁。 幸好，以下算法可以避免以上问题。来看看我们聪明的 C4 客户端怎么办： C4 向 lock.foo 发送 SETNX 命令。 因为崩溃掉的 C3 还锁着 lock.foo ，所以 Redis 向 C4 返回 0 。 C4 向 lock.foo 发送 GET 命令，查看 lock.foo 的锁是否过期。如果不，则休眠(sleep)一段时间，并在之后重试。 另一方面，如果 lock.foo 内的 unix 时间戳比当前时间戳老，C4 执行以下命令： GETSET lock.foo <current Unix timestamp + lock timeout + 1> 因为 GETSET 的作用，C4 可以检查看 GETSET 的返回值，确定 lock.foo 之前储存的旧值仍是那个过期时间戳，如果是的话，那么 C4 获得锁。 如果其他客户端，比如 C5，比 C4 更快地执行了 GETSET 操作并获得锁，那么 C4 的 GETSET 操作返回的就是一个未过期的时间戳(C5 设置的时间戳)。C4 只好从第一步开始重试。 注意，即便 C4 的 GETSET 操作对 key 进行了修改，这对未来也没什么影响。 这里假设锁key对应的value没有实际业务意义，否则会有问题，而且其实其value也确实不应该用在业务中。 为了让这个加锁算法更健壮，获得锁的客户端应该常常检查过期时间以免锁因诸如 DEL 等命令的执行而被意外解开，因为客户端失败的情况非常复杂，不仅仅是崩溃这么简单，还可能是客户端因为某些操作被阻塞了相当长时间，紧接着 DEL 命令被尝试执行(但这时锁却在另外的客户端手上)。 GETSET命令 语法： GETSET key value 功能： 将给定 key 的值设为 value ，并返回 key 的旧值(old value)。当 key 存在但不是字符串类型时，返回一个错误。 时间复杂度： O(1) 返回值： 返回给定 key 的旧值；当 key 没有旧值时，也即是， key 不存在时，返回 nil 。 ref by http://blog.csdn.net/hpb21/article/details/7893013 http://redis.readthedocs.org/en/latest/string/setnx.html

------2018.03.23—先写这么多-----

Redis分布式锁解决抢购问题

https://segmentfault.com/a/1190000011421467