Redis基础

什么是Redis

Redis(Remote Dictionary Server) 是一个使用 C 语言编写的，开源的（BSD许可）高性能非关系型（NoSQL）的数据库。Redis 可以存储键和五种不同类型的值之间的映射。键的类型只能为字符串，值支持五种数据类型：String，List，Set，Zset，Hash

与传统数据库不同的是 Redis 的数据是存在内存中的，所以读写速度非常快， 因此 redis 被广泛应用于缓存方向，每秒可以处理超过 10万次读写操作，是已知性能最快的Key-Value DB。另外，Redis 也经常用来做分布式锁。除此之外，Redis 支持事务 、持久化、LUA脚本、LRU驱动事件、多种集群方案。

Redis有哪些优缺点

优点

读写性能优异， Redis能读的速度是110000次/s，写的速度是81000次/s。

支持数据持久化，支持AOF和RDB两种持久化方式。

支持事务，Redis的所有操作都是原子性的，同时Redis还支持对几个操作合并后的原子性执行。

数据结构丰富，除了支持string类型的value外还支持hash、set、zset、list等数据结构。

支持主从复制，主机会自动将数据同步到从机，可以进行读写分离。

缺点

容量受到物理内存的限制，不能用作海量数据的高性能读写，因此Redis 适合的场景主要局限在较小数据量的高性能操作和运算上。

Redis 不具备自动容错和恢复功能，主机从机的宕机都会导致前端部分读写请求失败，需要等待机器重启或者手动切换前端的IP才能恢复。

主机宕机，宕机前有部分数据未能及时同步到从机，切换IP后还会引入数据不一致的问题，降低了系统的可用性。

Redis 较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。为避免这一问题，运维人员在系统上线时必须确保有足够的空间，这对资源造成了很大的浪费。

为什么要用 Redis 而不用 map做缓存?

缓存分为本地缓存和分布式缓存。以 Java 为例，使用自带的 map 实现的是本地缓存，最主要的特点是轻量以及快速，生命周期随着 jvm 的销毁而结束，但是在多实例的情况下，每个实例都需要各自保存一份缓存，缓存不具有一致性。使用 redis 在多实例的情况下，各实例共用一份缓存数据，缓存具有一致性。

Redis 可以用几十 G 内存来做缓存，Map 不行，一般 JVM 也就分几个 G 数据就够大了；

Redis 的缓存可以持久化，Map 是内存对象，程序一重启数据就没了；

Redis 可以实现分布式的缓存，Map 只能存在创建它的程序里；

Redis 可以处理每秒百万级的并发，是专业的缓存服务，Map 只是一个普通的对象；

Redis 缓存有过期机制，Map 本身无此功能；

Redis 有丰富的 API，Map 就简单太多了；

Redis为什么这么快

完全基于内存，绝大部分请求是纯粹的内存操作，非常快速。数据存在内存中，类似于 HashMap，HashMap 的优势就是查找和操作的时间复杂度都是O(1)；

数据结构简单，对数据操作也简单，Redis 中的数据结构是专门进行设计的；

redis是单线程的，省去了很多上下文切换线程的时间，也不存在多进程或者多线程导致的切换而消耗 CPU，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗；

redis使用多路复用技术，可以处理并发的连接。非阻塞IO 内部实现采用epoll，采用了epoll+自己实现的简单的事件框架。epoll中的读、写、关闭、连接都转化成了事件，然后利用epoll的多路复用特性，绝不在io上浪费一点时间

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

Redis有哪些数据类型

Redis主要有5种数据类型，包括String，List，Set，Zset，Hash，满足大部分的使用要求

String字符串类型

Redis支持的字符串类型不是定长分配的字符串，是动态变长字符串，修改字符串在没有增加特别多内容的情况下不需要重新分配内存空间，内部结构实现上有点类似于java的ArrayList，采用预分配冗余空间的方式来减少内存的频繁分配。

常用使用场景

字符串类型常用的场景有以下这些：

（1）缓存结构体信息

将结构体json序列化成字符串，然后将字符串保存在redis的value中，将结构体的业务唯一标示作为key；这种保存json的用法用的最多的场景就是缓存用户信息，将用户bean信息转成json再序列化为字符串作为value保存在redis中，将用户id作为key。从代码中获取用户缓存信息就是一个逆过程，根据userid作为key获取到结构体json，然后将json转成java bean。

127.0.0.1:6379> set user.10001 {“id”:”10001”,”name”:”monkey”}

(integer) 1

（2）计数功能

我们都知道redis是单线程模式，并且redis将很多常用的事务操作进行了封装，这里我们最常用的就是数值自增或自减，redis的作者封装了incr可以进行自增，每调用一次自增1，因为redis是单线程运行，所以就算client是多线程调用那么也是正确自增，因为incr命令中将read和write做了事务封装。同样可以设置incr的step，每次根据step进行自增，当然如果要达到自减的效果，那么只要将step设置为负数就可以了。

计数功能使用的场景很多，我们之前经常用在实时计数统计场景，也用在过库存场景、限流计数场景等等，而且redis的性能也是非常高的，对于一般的并发量没那么高的系统都是适用的。

127.0.0.1:6379> set num 1
127.0.0.1:6379> incr num
(integer) 2
127.0.0.1:6379> incrby num 2
(integer) 4

List列表类型

redis的列表的数据结构和Java中的LinkedList比较类似，所以List类型的前后插入和删除速度是非常快的，但是随机定位速度非常慢，时间复杂度是O（n）需要对列表进行遍历。

常用使用场景

（1）list列表结构常用来做异步队列使用

将需要延后处理的任务结构体序列化成字符串塞进 Redis 的列表，另一个线程从这个列表中轮询数据进行处理。

（2）list可用于秒杀抢购场景

在商品秒杀场景最怕的就是商品超卖，为了解决超卖问题，我们经常会将库存商品缓存到类似MQ的队列中，多线程的购买请求都是从队列中取，取完了就卖完了，但是用MQ处理的化有点重，这里就可以使用redis的list数据类型来实现，在秒杀前将本场秒杀的商品放到list中，因为list的pop操作是原子性的，所以即使有多个用户同时请求，也是依次pop，list空了pop抛出异常就代表商品卖完了。

//库存为3瓶可乐
> rpush goods:cola cola cola cola//rpush就是添加（生产）
(integer) 3
> lpop goods:cola//lpop就是取出（消费）
"cola"
> lpop goods:cola
"cola"

Hash数据类型

redis的hash相当于hashmap，内部实现上和hashmap一致，数组＋链表的数据结构。

redis的hash数据类型只能是字符串。它们 rehash 的方式不一样，因为 Java 的 HashMap 在字典很大时，rehash 是个耗时的操作，需要一次性全部 rehash。Redis 为了高性能，不能堵塞服务，所以采用了渐进式 rehash 策略。渐进式 rehash 会在 rehash 的同时，保留新旧两个 hash 结构，查询时会同时查询两个 hash 结构，然后在后续的定时任务中以及 hash 操作指令中，循序渐进地将旧 hash 的内容一点点迁移到新的 hash 结构中。当搬迁完成了，就会使用新的hash结构取而代之。 当 hash 移除了最后一个元素之后，该数据结构自动被删除，内存被回收。

常用使用场景

（1）保存结构体信息

hash字典类型也是比较适合保存结构体信息的，不同于字符串一次序列化整个对象，hash可以对用户结构中的每个字段单独存储。这样当我们需要获取结构体信息时可以进行部分获取，而不用序列化所有字段，而将整个字符串保存的结构体信息只能一次性全部读取。

127.0.0.1:6379> hset user.10002 name monkey
(integer) 1
127.0.0.1:6379> hget user.10002 name
"monkey"
127.0.0.1:6379> hgetall user.10002
1) "id"
2) "10002"
3) "name"
4) "monkey"

Set集合类型

redis的set相当于java中的HashSet，内部的健值是无序唯一的，相当于一个hashmap，但是value都是null。set数据类型其实没什么好讲的，使用场景也是比较单一的，就是用在一些去重的场景里，例如每个用户只能参与一次活动、一个用户只能中奖一次等等去重场景。

127.0.0.1:6379> sadd userset 10001
(integer) 1
127.0.0.1:6379> sadd userset 10002
(integer) 1
127.0.0.1:6379> sadd userset 10001
(integer) 0
127.0.0.1:6379> sadd userset 10003 10004
(integer) 2
127.0.0.1:6379> smembers userset
1) "10001"
2) "10002"
3) "10003"
4) "10004"

Zset有序集合

它类似于 Java 的 SortedSet 和 HashMap 的结合体，一方面它是一个 set，保证了内部 value 的唯一性，另一方面它可以给每个 value 赋予一个 score，代表这个 value 的排序权重。zset内部是通过跳跃列表这种数据结构来实现的。因为zset要支持随机的插入和删除，所以不能使用数组结构，而需要改成普通链表数据结构。zset需要根据score进行排序，所以每次插入或者删除值都需要进行先在链表上查找定位。

常用使用场景是各类热门排序场景

例如热门歌曲榜单列表，value值是歌曲ID，score是播放次数，这样就可以对歌曲列表按播放次数进行排序。

当然还有类似微博粉丝列表、评论列表等等，可以将value定义为用户ID、评论ID，score定义为关注时间、评论点赞次数等等。

127.0.0.1:6379> zadd userzset 100 10002 //zadd keyname score value
(integer) 1
127.0.0.1:6379> zadd userzset 98 10001
(integer) 1
127.0.0.1:6379> zrange userzset 0 100
1) "10001"
2) "10002"

什么是Redis持久化？

持久化就是把内存的数据写到磁盘中去，防止服务宕机了内存数据丢失。

Redis 的持久化机制是什么？各自的优缺点？

Redis 提供两种持久化机制 RDB（默认） 和 AOF 机制:

1、RDB

是Redis DataBase缩写快照，RDB是Redis默认的持久化方式。按照一定的时间将内存的数据以快照的形式保存到硬盘中，对应产生的数据文件为dump.rdb。通过配置文件中的save参数来定义快照的周期。

优点：

1、只有一个文件 dump.rdb，方便持久化。

2、容灾性好，一个文件可以保存到安全的磁盘。

3、性能最大化，fork 子进程来完成写操作，让主进程继续处理命令，所以是

IO 最大化。使用单独子进程来进行持久化，主进程不会进行任何 IO 操作，保证了redis 的高性能

4、相对于数据集大时，比 AOF 的启动效率更高。

缺点：

数据安全性低。RDB 是间隔一段时间进行持久化，如果持久化之间 redis 发

生故障，会发生数据丢失。所以这种方式更适合数据要求不严谨的时候

2、AOF

AOF持久化，AOF持久化(即Append Only File持久化)，则是将Redis执行的每次写命令记录到单独的日志文件中（每一次持久化都会有一个新的日志文件，所以日志文件数量多），当重启Redis会重新将持久化的日志文件中恢复数据，当两种方式同时开启时，数据恢复Redis会优先选择AOF恢复。

优点：

1、数据安全，aof 持久化可以配置 appendfsync 属性，有 always，每进行一

次 命令操作就记录到 aof 文件中一次。

2、通过 append 模式写文件，即使中途服务器宕机，可以通过 redis-check- aof 工具解决数据一致性问题。

3、AOF 机制的 rewrite 模式。AOF 文件没被 rewrite 之前（文件过大时会对命令 进行合并重写），可以删除其中的某些命令（比如误操作的 flushall）)

缺点：

1、AOF 文件比 RDB 文件大，且恢复速度慢。

2、数据集大的时候，比 rdb 启动效率低。

好文参考：Redis持久化机制，优缺点，如何选择合适方式 - 知乎

如何选择合适的持久化方式

1、一般来说， 如果想达到足以媲美PostgreSQL的数据安全性，你应该同时使用两种持久化功能。在这种情况下，当 Redis 重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。

2、如果你非常关心你的数据， 但仍然可以承受数分钟以内的数据丢失， 那么你可以只使用RDB持久化。

3、有很多用户都只使用AOF持久化，但并不推荐这种方式，因为定时生成RDB快照（snapshot）非常便于进行数据库备份， 并且 RDB 恢复数据集的速度也要比AOF恢复的速度要快，除此之外，使用RDB还可以避免AOF程序的bug。

4、如果你只希望你的数据在服务器运行的时候存在，你也可以不使用任何持久化方式。

Redis持久化数据和缓存怎么做扩容？

• 如果Redis被当做缓存使用，使用一致性哈希实现动态扩容缩容。
• 如果Redis被当做一个持久化存储使用，那就要搭建Redis集群做扩容

Redis key的过期时间和永久有效分别怎么设置？

Redis 设置自定义过期时间

EXPIRE

接口定义：EXPIRE key "seconds"

接口描述：设置一个key在当前时间"seconds"(秒)之后过期。返回1代表设置成功，返回0代表key不存在或者无法设置过期时间。

PEXPIRE

接口定义：PEXPIRE key "milliseconds"

接口描述：设置一个key在当前时间"milliseconds"(毫秒)之后过期。返回1代表设置成功，返回0代表key不存在或者无法设置过期时间。

127.0.0.1:6379> set aa bb
OK
127.0.0.1:6379> EXPIRE aa 60
(integer) 1
127.0.0.1:6379> EXPIRE aa 600
(integer) 1

Redis 设置永久有效

PERSIST

接口定义：PERSIST key

接口描述：移除key的过期时间，将其转换为永久状态。如果返回1，代表转换成功。如果返回0，代表key不存在或者之前就已经是永久状态。

127.0.0.1:6379> set aa bb
OK
127.0.0.1:6379> EXPIRE  aa 600
(integer) 1
127.0.0.1:6379> ttl aa
(integer) 596
127.0.0.1:6379> PERSIST aa
(integer) 1
127.0.0.1:6379> ttl aa
(integer) 1

如何保证redis中的数据都是热点数据？

对于保留 Redis 热点数据来说，我们可以使用 Redis 的内存淘汰策略来实现，可以使用allkeys-lru淘汰策略，该淘汰策略是从 Redis 的数据中挑选最近最少使用的数据删除，这样频繁被访问的数据就可以保留下来了。7

Redis的内存淘汰策略有哪些

Redis 6种内存淘汰策略

noeviction：当内存不足以容纳新写入数据时，新写入操作会报错。

allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的key。（这个比较常用）

allkeys-random：当内存不足以容纳新写入数据时，在键空间中，随机移除某个key。

volatile-lru：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，移除最近最少使用的key。

volatile-random：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，随机移除某个key。

volatile-ttl：当内存不足以容纳新写入数据时，从配置了过期时间的键中移除马上就要过期的键

总结

Redis的内存淘汰策略的选取并不会影响过期的key的处理。内存淘汰策略用于处理内存不足时的需要申请额外空间的数据；过期策略用于处理过期的缓存数据。

Redis主要消耗什么物理资源？

内存

Redis的内存用完了会发生什么？

这个跟 Redis 的内存回收策略有关。

Redis 的默认回收策略是 noenviction，当内存用完之后，写数据会报错。

Redis 的其他内存回收策略含义：

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)中，随机淘汰数据

Redis如何做内存优化？

1、缩减键值对象

降低Redis内存使用最直接的方式就是缩减键（key）和值（value）的长度。

key长度：如在设计键时，在完整描述业务情况下，键值越短越好。

value长度：值对象缩减比较复杂，常见需求是把业务对象序列化成二进制数组放入Redis。首先应该在业务上精简业务对象，去掉不必要的属性避免存储无效数据。其次在序列化工具选择上，应该选择更高效的序列化工具来降低字节数组大小。以JAVA为例，内置的序列化方式无论从速度还是压缩比都不尽如人意，这时可以选择更高效的序列化工具，如: protostuff，kryo等下图是JAVA常见序列化工具空间压缩对比。

其中java-built-in-serializer表示JAVA内置序列化方式，更多数据见jvm-serializers项目:https://github.com/eishay/jvm-serializers/wiki，其它语言也有各自对应的高效序列化工具。

值对象除了存储二进制数据之外，通常还会使用通用格式存储数据比如:json，xml等作为字符串存储在Redis中。这种方式优点是方便调试和跨语言，但是同样的数据相比字节数组所需的空间更大，在内存紧张的情况下，可以使用通用压缩算法压缩json,xml后再存入Redis，从而降低内存占用，例如使用GZIP压缩后的json可降低约60%的空间。

开发提示：当频繁压缩解压json等文本数据时，开发人员需要考虑压缩速度和计算开销成本，这里推荐使用google的Snappy压缩工具，在特定的压缩率情况下效率远远高于GZIP等传统压缩工具，且支持所有主流语言环境。开发提示：当频繁压缩解压json等文本数据时，开发人员需要考虑压缩速度和计算开销成本，这里推荐使用google的Snappy压缩工具，在特定的压缩率情况下效率远远高于GZIP等传统压缩工具，且支持所有主流语言环境。

2、共享对象池

对象共享池指Redis内部维护[0-9999]的整数对象池。创建大量的整数类型redisObject存在内存开销，每个redisObject内部结构至少占16字节，甚至超过了整数自身空间消耗。所以Redis内存维护一个[0-9999]的整数对象池，用于节约内存。 除了整数值对象，其他类型如list,hash,set,zset内部元素也可以使用整数对象池。因此开发中在满足需求的前提下，尽量使用整数对象以节省内存。

3、控制key的数量

当使用Redis存储大量数据时，通常会存在大量键，过多的键同样会消耗大量内存。Redis本质是一个数据结构服务器，它为我们提供多种数据结构，如hash，list，set，zset 等结构。使用Redis时不要进入一个误区，大量使用get/set这样的API，把Redis当成Memcached使用。对于存储相同的数据内容利用Redis的数据结构降低外层键的数量，也可以节省大量内存。如下图所示，通过在客户端预估键规模，把大量键分组映射到多个hash结构中降低键的数量。

hash结构降低键数量分析：

根据键规模在客户端通过分组映射到一组hash对象中，如存在100万个键，可以映射到1000个hash中，每个hash保存1000个元素。

hash的field可用于记录原始key字符串，方便哈希查找。

hash的value保存原始值对象，确保不要超过hash-max-ziplist-value限制。

4、字符串优化

5、编码优化

Redis线程模型

redis 内部使用文件事件处理器 (file event handler)，这个文件事件处理器是单线程的，所以 redis 才叫做单线程的模型。它采用 IO 多路复用机制同时监听多个 socket（扫 k以3 t），根据 socket 上的事件来选择对应的事件处理器进行处理。

文件事件处理器的结构包含 4 个部分

• 多个 socket
• IO 多路复用程序
• 文件事件分派器
• 事件处理器（包括：连接应答处理器、命令请求处理器、命令回复处理器）

多个 socket 可能会并发产生不同的操作，每个操作对应不同的文件事件，但是 IO 多路复用 程序会监听多个 socket，会将 socket 产生的事件放入队列中排队，文件事件分派器每次从队列中取出一个事件，把该事件交给对应的事件处理器进行处理。

补充： IO 多路复用是指单线程或单进程同时监测若干个文件描述符是否可以执行IO操作的能力。

来看客户端与 redis 的一次通信过程

1.客户端 socket01 向 redis 的 server socket 请求建立连接，此时 server socket 会产生一个 AE_READABLE 事件，IO 多路复用程序监听到 server socket 产生的事件后，将该事件压入队列中。文件事件分派器从队列中获取该事件，交给连接应答处理器。连接应答处理器会创建一个能与客户端通信的 socket01，并将该 socket01 的 AE_READABLE 事件与命令请求处理器关联。

2.假设此时客户端发送了一个 set key value 请求，此时 redis 中的 socket01 会产生 AE_READABLE 事件，IO 多路复用程序将事件压入队列，此时事件分派器从队列中获取到该事件，由于前面 socket01 的 AE_READABLE 事件已经与命令请求处理器关联，因此事件分派器将事件交给命令请求处理器来处理。命令请求处理器读取 socket01 的 key value 并在自己内存中完成 key value 的设置。操作完成后，它会将 socket01 的 AE_WRITABLE 事件与命令回复处理器关联。

3.如果此时客户端准备好接收返回结果了，那么 redis 中的 socket01 会产生一个 AE_WRITABLE 事件，同样压入队列中，事件分派器找到相关联的命令回复处理器，由命令回复处理器对 socket01 输入本次操作的一个结果，比如 ok，之后解除 socket01 的 AE_WRITABLE 事件与命令回复处理器的关联。

这样便完成了一次通信。

为啥 redis 单线程模型也能效率这么高？

• 纯内存操作
• 核心是基于非阻塞的 IO 多路复用机制
• 单线程反而避免了多线程的频繁上下文切换问题

Redis如何提高多核CPU的利用率？

redis的读取和处理性能非常强大，一般服务器的cpu都不会是性能瓶颈。redis的性能瓶颈主要集中在内存和网络方面。所以，如果使用的redis命令多为O(N)、O(log(N))时间复杂度，那么基本上不会出现cpu瓶颈的情况。

但是如果你确实需要充分使用多核cpu的能力，那么需要在单台服务器上运行多个redis实例(主从部署/集群化部署)，并使用 taskset命令将每个redis实例和cpu内核进行绑定，如果需要进行集群化部署，你需要对redis进行分片存储

如何解决 Redis 的并发竞争 Key 问题

并发竞争key这个问题简单讲就是：

同时有多个客户端去set一个key

方案一

使用分布式锁（zookeeper 和 redis 都可以实现分布式锁），如果不存在 Redis 的并发竞争 Key 问题，不要使用分布式锁，这样会影响性能

方案二

利用消息队列，在并发量过大的情况下,可以通过消息中间件进行处理,把并行读写进行串行化，把Redis.set操作放在队列中使其串行化,必须的一个一个执行。

这种方式在一些高并发的场景中算是一种通用的解决方案。

Redis实现分布式锁

什么是分布式锁？

分布式锁其实就是，控制分布式系统不同进程共同访问共享资源的一种锁的实现。如果不同的系统或同一个系统的不同主机之间共享了某个临界资源，往往需要互斥来防止彼此干扰，以保证一致性。

分布式锁的特性

「互斥性」: 任意时刻，只有一个客户端能持有锁。

「锁超时释放」：持有锁超时，可以释放，防止不必要的资源浪费，也可以防止死锁。

「可重入性」:一个线程如果获取了锁之后,可以再次对其请求加锁。

「高性能和高可用」：加锁和解锁需要开销尽可能低，同时也要保证高可用，避免分布式锁失效。

「安全性」：锁只能被持有的客户端删除，不能被其他客户端删除

分布式锁如何实现

作为分布式锁实现过程中的共享存储系统，Redis可以使用键值对来保存锁变量，在接收和处理不同客户端发送的加锁和释放锁的操作请求。那么，键值对的键和值具体是怎么定的呢？我们要赋予锁变量一个变量名，把这个变量名作为键值对的键，而锁变量的值，则是键值对的值，这样一来，Redis就能保存锁变量了，客户端也就可以通过Redis的命令操作来实现锁操作。

想要实现分布式锁，必须要求Redis有互斥的能力。可以使用SETNX命令，其含义是SET IF NOT EXIST，即如果key不存在，才会设置它的值，否则什么也不做。两个客户端进程可以执行这个命令，达到互斥，就可以实现一个分布式锁。

以下展示了Redis使用key/value对保存锁变量，以及两个客户端同时请求加锁的操作过程。

加锁操作完成后，加锁成功的客户端，就可以去操作共享资源，例如，修改MySQL的某一行数据。操作完成后，还要及时释放锁，给后来者让出操作共享资源的机会。如何释放锁呢？直接使用DEL命令删除这个key即可。这个逻辑非常简单，整体的流程写成伪代码就是下面这样。

// 加锁

SETNX lock_key 1

// 业务逻辑

DO THINGS

// 释放锁

DEL lock_key

但是，以上实现存在一个很大的问题，当客户端1拿到锁后，如果发生下面的场景，就会造成死锁。

程序处理业务逻辑异常，没及时释放锁

进程挂了，没机会释放锁

以上情况会导致已经获得锁的客户端一直占用锁，其他客户端永远无法获取到锁。

如何避免死锁

为了解决以上死锁问题，最容易想到的方案是在申请锁时，在Redis中实现时，给锁设置一个过期时间，假设操作共享资源的时间不会超过10s，那么加锁时，给这个key设置10s过期即可。

但以上操作还是有问题，加锁、设置过期时间是2条命令，有可能只执行了第一条，第二条却执行失败，例如：

SETNX执行成功，执行EXPIRE时由于网络问题，执行失败

SETNX执行成功，Redis异常宕机，EXPIRE没有机会执行

SETNX执行成功，客户端异常崩溃，EXPIRE没有机会执行

总之这两条命令如果不能保证是原子操作，就有潜在的风险导致过期时间设置失败，依旧有可能发生死锁问题。幸好在Redis 2.6.12之后，Redis扩展了SET命令的参数，可以在SET的同时指定EXPIRE时间，这条操作是原子的，例如以下命令是设置锁的过期时间为10秒。

SET lock_key 1 EX 10 NX

至此，解决了死锁问题，但还是有其他问题。想像下面这个这样一种场景：

• 客户端1加锁成功，开始操作共享资源
• 客户端1操作共享资源耗时太久，超过了锁的过期时间，锁失效（锁被自动释放）
• 客户端2加锁成功，开始操作共享资源
• 客户端1操作共享资源完成，在finally块中手动释放锁，但此时它释放的是客户端2的锁。