概述

在关系型数据库中，事务是指一组命令的集合，这组命令构成了一个原子操作，这个操作要么全部执行成功，要么全部执行失败。而在非关系型数据库 Redis 中并非这样…

Redis事务机制

严格意义来讲,Redis的事务和我们理解的传统数据库(如mysql)的事务是不一样的；Redis的事务实质上是命令的集合，在一个事务中要么所有命令都被执行，要么所有事物都不执行。
一个事务从开始到执行会经历以下三个阶段：

开始事务。开启成功返回ok
命令入队。入队成功返回一个QUEUED
执行事务。执行成功返回一个或多个ok

Redis中我们使用MULTI 开始一个事务，由 EXEC 命令触发事务，一并执行事务中的所有命令。

multi： 开启一个事务，类似 MySQL 中的 begin transaction。
discard：放弃事务，事务回到开始，类似 MySQL 中的 rowback。
exec： 提交事务，类似 MySQL 中的 commit。

Redis 事务有几种玩法？

正常执行：

放弃事务：

全体连坐：

冤头债主：

注：如果命令本身的语法并没有错误，只是在事务执行的时候某条命令出了错，那么其他的命令不会回滚，正常执行，出错的命令执行失败。

Redis事务错误处理

如果一个事务中的某个命令执行出错，Redis会怎样处理呢？要回答这个问题，首先要搞清楚是什么原因导致命令执行出错：

语法错误 就像上面的例子一样，语法错误表示命令不存在或者参数错误（例如全体连坐）
这种情况需要区分Redis的版本，Redis 2.6.5之前的版本会忽略错误的命令，执行其他正确的命令，2.6.5之后的版本会忽略这个事务中的所有命令，都不执行，就比如上面的例子(使用的Redis版本是2.8的)
运行错误 运行错误表示命令在执行过程中出现错误，比如用GET命令获取一个散列表类型的键值。
这种错误在命令执行之前Redis是无法发现的，所以在事务里这样的命令会被Redis接受并执行。如果食物里有一条命令执行错误，其他命令依旧会执行（包括出错之后的命令）。（冤头债主）比如下例：

127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> set key 1
QUEUED
127.0.0.1:6379> SADD key 2
QUEUED
127.0.0.1:6379> set key 3
QUEUED
127.0.0.1:6379> EXEC
1) OK
2) (error) WRONGTYPE Operation against a key holding the wrong kind of value
3) OK
127.0.0.1:6379> get key
"3"

Redis 事务有哪些特性？

Redis 事务中的所有命令都会存放在队列中按序执行。
Redis 事务中的所有命令在没有提交（exec）之前，都不会执行，所以也就不存在关系型数据库中经常出现的脏读，不可重复读，幻读等并发操作的问题。
Redis 事务不保证原子性，也就是上面说的，命令如果本身的语法没有问题，只是在执行的过程中出错，不影响其他命令的执行。

WATCH命令

从上面的例子我们可以看到，事务中的命令要全部执行完之后才能获取每个命令的结果，但是如果一个事务中的命令B依赖于他上一个命令A的结果的话该怎么办呢？就比如说实现类似Java中的i++的功能，先要获取当前值，才能在当前值的基础上做加一操作。这种场合仅仅使用上面介绍的MULTI和EXEC是不能实现的，因为MULTI和EXEC中的命令是一起执行的，并不能将其中一条命令的执行结果作为另一条命令的执行参数，所以这个时候就需要引进Redis事务家族中的另一成员：WATCH命令

WATCH 命令可以为 Redis 事务提供 check-and-set （CAS）行为。被 WATCH 的键会被监视，并会发觉这些键是否被改动过了。如果有至少一个被监视的键在 EXEC 执行之前被修改了，那么整个事务都会被取消， EXEC 返回nil-reply来表示事务已经失败。

换个角度思考上面说到的实现i++的方法，可以这样实现：

监控i的值，保证i的值不被修改

获取i的原值

如果过程中i的值没有被修改，则将当前的i值+1，否则不执行

这样就能够避免竞态条件，保证i++能够正确执行。

WATCH命令可以监控一个或多个键，一旦其中有一个键被修改（或删除），之后的事务就不会执行，监控一直持续到EXEC命令（事务中的命令是在EXEC之后才执行的，EXEC命令执行完之后被监控的键会自动被UNWATCH）

举个例子：

127.0.0.1:6379> set mykey 1
OK
127.0.0.1:6379> WATCH mykey
OK
127.0.0.1:6379> set mykey 2
OK
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> set mykey 3
QUEUED
127.0.0.1:6379> EXEC
(nil)
127.0.0.1:6379> get mykey
"2"
127.0.0.1:6379>

上面的例子中，首先设置mykey的键值为1，然后使用WATCH命令监控mykey，随后更改mykey的值为2，然后进入事务，事务中设置mykey的值为3，然后执行EXEC运行事务中的命令，最后使用get命令查看mykey的值，发现mykey的值还是2，也就是说事务中的命令根本没有执行（因为WATCH监控mykey的过程中，mykey被修改了，所以随后的事务便会被取消）。

注意：由于WATCH命令的作用只是当被监控的键被修改后取消之后的事务，并不能保证其他客户端不修改监控的值，所以当EXEC命令执行失败之后需要手动重新执行整个事务。

分布式锁

什么是分布式锁？

分布式锁是控制分布式系统之间同步访问共享资源的一种方式。如果不同的系统或是同一个系统的不同主机之间共享了一个或一组资源，那么访问这些资源的时候，往往需要互斥来防止彼此干扰来保证一致性，在这种情况下，便需要使用到分布式锁。

实现分布式锁有很多实现方式和工具，如Zookeeper、Redis等。

使用Redis实现分布式锁原理：

Redis为单进程单线程模式，采用队列模式将并发访问变成串行访问，且多客户端对Redis的连接并不存在竞争关系，基于此，Redis中可以使用SETNX命令实现分布式锁。

SETNX——SET if Not eXists（如果不存在，则设置）：

setnx key value

将 key 的值设为 value ，当且仅当 key 不存在。若给定的 key 已经存在，则 SETNX 不做任何动作。

如果需要解锁，使用 del key 命令就能释放锁：

左图首先使用setnx对键加锁成功返回1，右图再次使用setnx命令对键加锁失败返回0，说明有客户端持有锁。使用del释放锁以后，右图就可以使用setnx命令对键加锁。

解决死锁

如果一个持有锁的客户端失败或崩溃了不能释放锁，该怎么解决？

答：给锁设置一个过期时间，可以通过两种方法实现：通过命令 “setnx 键名过期时间 “；或者通过设置锁的expire时间，让Redis去删除锁。

第一种实现方式：
使用 setnx key “当前系统时间+锁持有的时间”和getset key “当前系统时间+锁持有的时间”组合的命令就可以实现。
具体做法如下：

客户端2发送SETNX lock.test 想要获得锁，由于之前的客户端1还持有锁，所以Redis返回一个0
客户端2发送GET lock.test 以检查锁是否超时了，如果没超时，则等待或重试。
反之，如果已超时，客户端2通过下面的操作来尝试获得锁：
GETSET lock.test 过期的时间
通过GETSET，客户端2拿到的时间戳如果仍然是超时的，那就说明，客户端2如愿以偿拿到锁了。
如果在客户端2之前，有个客户端3比客户端2快一步执行了上面的操作，那么客户端2拿到的时间戳是个未超时的值，这时，说明客户端2没有如期获得锁，需要再次等待或重试。
尽管客户端2没拿到锁，但它改写了客户端3设置的锁的超时值，不过这一点非常微小的误差带来的影响可以忽略不计。

第二种就非常简单了：
通过Redis中expire()给锁设定最大持有时间，如果超过，则Redis来帮我们释放锁。

客户端1使用setnx获得了锁，并且使用expire设定一个过期时间，假定是10ms
过了4ms后，客户端1不幸运的宕机了，此时客户端2想要通过setnx尝试获得锁，但是锁还没有过期，任然被客户端1所持有。
到了11ms时，锁过期了，Redis帮我们删除了锁，此时客户端2想要通过setnx尝试获得锁，此时就能成功获得锁。

在实际过程中，我们可以设定一个时间T，用来表示客户端在初次尝试获得锁失败以后，在多次尝试获得锁所花的时间。如果次时间为0，表示除此尝试获得锁失败以后就不会再去尝试获得锁了。

Redis事务、分布式锁

概述