&　　我们都知道redis追求的是简单，快速，高效，在这种情况下也就拒绝了支持window平台，学sqlserver的时候，我们知道事务还算是个比较复杂的东西，
所以这吊毛要是照搬到redis中去，理所当然redis就不是那么简单纯碎的东西了，但是呢，事务是我们写程序无法逃避的场景，所以redis作者折衷的写了个简
化版的事务机制，下面我来扯一下它的蛋蛋。
一： 事务实战
　　具体到事务是什么，要保证什么。。。这个我想没必要说了，先不管三七二十一，看一下redis手册，领略下它的魔力。
1. multi，exec
& &还记得sqlserver是怎么玩的吗？一般都是这样的三个步骤，生成事务，产生命令，执行事务，对吧，而对应redis呢？？multi就是生成事务，然后
输入redis命令，最后用exec执行命令，就像下面这样：
可以看到，我set完命令之后，反馈信息是QUEUED，最后我再执行exec，这些命令才会真正的执行，就是这么的简单，一切执行的就是那么的顺利，
一点都不拖泥带水，牛逼的不要不要的，可能有些人说，其实事务中还有一个rollback操作，但好像在redis中没有看到，哈哈，牛逼哈，很遗憾是
redis中没有rollback操作，比如下面这样。
在图中我故意用lpush命令去执行string，可想而知自然不会执行成功，但从结果中，你看到什么了呢？两个OK，一个Error，这就是违反了事务
的原子性，对吧，但是我该怎么反驳呢？？？ 我会说，错你妹啊。。。连个基本的命令都写错了，你搞个毛啊。。。还写个吊毛代码，reids仅仅
是个数据结构服务器，多简单的一件事情，退一万步说，很明显的错误命令它会直接返回的，比如我故意把lpush写成lpush1：
　 不知道你看完multi后面的三条set命令之后，有没有一种心虚的感觉，怎么说呢，就是只要命令是正确的，redis保证会一并执行，誓死完成
任务，虽然说命令是一起执行的，但是谁可以保证我在执行命令的过程中，其他client不会修改这些值呢？？？如果修改了这些值，那我的exec
还有什么意义呢？？？没关系，这种烂大街的需求，redis怎可能袖手旁观？？？这里的watch就可以助你一臂之力。
WATCH key [key ...]
监视一个(或多个) key ，如果在事务执行之前这个(或这些) key 被其他命令所改动，那么事务将被打断。
　上面就是redis手册中关于watch的解释，使用起来貌似很简单，就是我在multi之前，用watch去监视我要修改的key，如果说我在exec之前，
multi之后的这段时间，key被其他client修改，那么exec就会执行失败，返回（nil），就这么简单，我还是来举个例子：
二：原理探索
　　关于事务操作的源代码，大多都在redis源码中的multi.c 文件中，接下来我会一个一个的简单剖析一下：
　　在redis的源代码中，它大概是这么写的：
1 void multiCommand(redisClient *c) {
if (c-&flags & REDIS_MULTI) {
addReplyError(c,"MULTI calls can not be nested");
c-&flags |= REDIS_MULTI;
addReply(c,shared.ok);
从这段代码中，你可以看到multi只是简单的把redisClient的REDIS_MULTI状态打开，告诉这个redis客户端已经进入事务模式了，对吧。
2. 生成命令
在redisClient中，里面有一个multiState命令：
typedef struct redisClient {
/* MULTI/EXEC state */
从注释中你大概也看到了这个命令和multi/exec肯定有关系，接下来我很好奇的看看multiState的定义：
typedef struct multiState {
multiCmd *
/* Array of MULTI commands */
/* Total number of MULTI commands */
/* MINREPLICAS for synchronous replication */
time_t minreplicas_ /* MINREPLICAS timeout as unixtime. */
从multiState这个枚举中，你可以看到下面有一个*command命令，从注释中可以看到它其实指向的是一个数组，这个数组我想你闭着眼睛都
能想得到吧。。。它就是你的若干条命令啦。。。下面还有一个count，可以看到是实际的commands的总数。
& & 为了方便说到后面的exec，这里想说一下watch大概是怎么实现的，在multi.c源代码中是这样写的。
1 typedef struct watchedKey {
4 } watchedK
6 void watchCommand(redisClient *c) {
if (c-&flags & REDIS_MULTI) {
addReplyError(c,"WATCH inside MULTI is not allowed");
for (j = 1; j & c-& j++)
watchForKey(c,c-&argv[j]);
addReply(c,shared.ok);
18 /* Watch for the specified key */
19 void watchForKey(redisClient *c, robj *key) {
list *clients = NULL;
listNode *
watchedKey *
/* Check if we are already watching for this key */
listRewind(c-&watched_keys,&li);
while((ln = listNext(&li))) {
wk = listNodeValue(ln);
if (wk-&db == c-&db && equalStringObjects(key,wk-&key))
return; /* Key already watched */
/* This key is not already watched in this DB. Let's add it */
clients = dictFetchValue(c-&db-&watched_keys,key);
if (!clients) {
clients = listCreate();
dictAdd(c-&db-&watched_keys,key,clients);
incrRefCount(key);
listAddNodeTail(clients,c);
/* Add the new key to the list of keys watched by this client */
wk = zmalloc(sizeof(*wk));
wk-&db = c-&
incrRefCount(key);
listAddNodeTail(c-&watched_keys,wk);
这段代码中大概最核心的一点就是：
/* This key is not already watched in this DB. Let's add it */
clients = dictFetchValue(c-&db-&watched_keys,key);
就是通过dicFetchValue这个字典方法，从watched_keys中找到指定key的value，而这个value是一个clients的链表，说明人家其实是想找到
关于这个key的所有client，对吧，最后还会将本次key塞入到redisclient的watched_keys字典中，如下代码：
/* Add the new key to the list of keys watched by this client */
wk = zmalloc(sizeof(*wk));
wk-&db = c-&
incrRefCount(key);
listAddNodeTail(c-&watched_keys,wk);
如果非要画图，大概就是这样：
其中watched_key是个字典结构，字典的键为上面的key1，key2。。。，value为client的链表，这样的话，我就非常清楚某个key
中是被哪些client监视着的，对吧。
& & 这个命令里面大概做了两件事情：
&1&: & 判断c-&flags=REDIS_DIRTY_EXEC 打开与否，如果是的话，取消事务discardTransaction(c)，也就是说这个key已经
& & & & & 被别的client修改了。
&2&: & 如果没有修改，那么就for循环执行comannd[]中的命令，如下图中的两处信息：
好了，大概就这么说了，希望对你有帮助哈~~~
阅读(...) 评论()眼眸深邃、轮廓分明、身材颀长，活生生的一幅画。
这在监狱民警看来，那么令人不可思议。
声明：本文由入驻搜狐公众平台的作者撰写，除搜狐官方账号外，观点仅代表作者本人，不代表搜狐立场。
　　redis 是一个高性能的key-value 数据库。作为no sql 数据库redis 与传统关系型数据库相比有简单灵活、数据结构丰富、高速读写等优点。
　　本文主要针对redis 在事物方面的处理与传统关系型数据库（使用mysql）进行比对，所使用的环境为ubuntu 14.04.1，mysql 5.5.49，redis 3.2.3。
　　1操作事务命令
　　mysql 使用start transaction 开启事物，rollback 回滚事物，commit 提交事物。redis 使用multi 开始事物，discard 取消事物，exec 提交事物。开始实验前为mysql 和redis 准备测试数据，tom1 账户准备1000元，tom2 账户准备500元。
（图1-数据准备）
　　场景1：使用事务从tom1转100元到tom2 。
　　步骤如下：
　　开启事物
　　start transaction
　　tom1 - 100
　　update tom1
　　decrty tom1 100　　queued
　　查询tom1 余额
　　tom1余额减少了100
　　get tom1　　queued
　　tom2 + 100
　　update tom2
　　incrby tom2 100　　queued
　　查询tom2 余额
　　tom2余额增加了100
　　get tom2　　queued
　　提交事物
　　commit
　　exec　　执行queue中的语句。　　1) (integer) 900　　2) &900&　　3) (integer) 600　　4) &600&
　　查询tom1，tom2余额
　　select * from account where name in (‘tom1’,’tom2’);　　tom1金额减少100，tom2账户增加了100
　　mget tom1 tom2　　tom1金额减少100，tom2账户增加了100
（图2-mysql 事务执行过程）
（图3-redis 事务执行过程）
　　从场景1中可以看出mysql 开启事务后事务中的sql 语句在commit 之前就已经执行了sql 语句的，只是并未真正提交到数据库。redis 使用multi 开启事务后，编写的sql 语句都进入queue 队列中，待执行exec 提交事物时才一次性按进入queue 队列的顺序提交到数据库。同样针对回滚，mysql 执行rollback 会将提交的数据回滚，redis 因为没有提交到数据，使用discard 只是单纯取消在queue 中的sql 语句。
　　场景2： 在执行tom1 向tom2 转过程中100元的过程中使用了语法错误的sql。
　　步骤如下：
　　开启事物
　　start transaction
　　tom1 - 100
　　update tom1
　　decrty tom1 100　　queued
　　查询tom1 余额
　　tom1余额减少了100
　　get tom1　　queued
　　tom2 + 100
　　使用错误命令为tom2+100
　　使用错误命令为tom2+100
　　查询tom2 余额
　　tom2余额未变
　　get tom2　　queued
　　提交事物
　　commit
　　exec　　因为queue中存在语法错误的语句，直接discard事务中的语句
　　查询tom1，tom2余额
　　select * from account where name in (‘tom1’,’tom2’);　　tom1金额减少100，tom2账户金额未变
　　mget tom1 tom2　　tom1,tom2金额未变
（图4-mysql 事务中存在语法错误语句）
（图5-redis 事务中存在语法错误语句）
　　从场景2中可以看出，mysql 事务即使遇到错误的语句也会提交正确的sql 到数据库，需要程序员控制当遇到语句异常时进行回滚，redis 与mysql 不同，提交事务时当queue 中有语法错误语句会discard 整个事务中的sql 语句。
　　场景3： 在执行tom1 向tom2 转过程中100元的过程中使用了错误的执行对象。
　　步骤如下：
　　开启事物
　　start transaction
　　tom1 - 100
　　update tom1
　　decrty tom1 100　　queued
　　查询tom1 余额
　　tom1余额减少了100
　　get tom1　　queued
　　tom2 + 100
　　使用错误对象命令为tom2+’hundrud’
　　使用错误命令为tom2+’hundred’
　　查询tom2 余额
　　tom2余额未变
　　get tom2　　queued
　　提交事物
　　commit
　　exec　　逐条执行
　　查询tom1，tom2余额
　　select * from account where name in (‘tom1’,’tom2’);　　tom1金额减少100，tom2账户金额未变
　　mget tom1 tom2　　tom1金额减少100，tom2账户金额未变
（图6-mysql 中存在操作错误对象的sql 语句）
（图7-redis 中存在操作错误对象的sql语句）
　　从场景3中可以看出，mysql 和redis 事务当遇到操作对象类型不正确的时候都会提交执行事务。
　　2事务锁
　　在关系型数据库中主要通过乐观锁和悲观锁进行数据库事务的并发控制。而在redis 中是通过watch 加乐观锁对数据库进行并发控制。
　　mysql 悲观锁是通过select * from table where &condition& for update将数据加锁，导致其他线程或事务不能更新该数据。相对于悲观锁，在对数据库进行处理的时候，乐观锁并不会使用数据库提供的锁机制。一般的实现乐观锁的方式就是记录数据版本。数据版本为数据增加的一个版本标识。当读取数据时，将版本标识的值一同读出，数据每更新一次，同时对版本标识进行更新。当我们提交更新的时候，判断数据库表对应记录的当前版本信息与第一次取出来的版本标识进行比对，如果数据库表当前版本号与第一次取出来的版本标识值相等，则予以更新，否则认为是过期数据。
　　关系型数据库mysql 实现数据版本主要有两种方式，第一种是使用版本号，第二种是使用时间戳。使用版本号时，可以在数据初始化时指定一个版本号，每次对数据的更新操作都对版本号执行+1操作。并判断当前版本号是不是该数据的最新的版本号。
（图8-mysql乐观锁）
　　图8展示了mysql 乐观锁的示例，开启两个mysql 客户端，客户端1执行start transaction 查询数据，这时客户端2更新了客户端1查询到的数据及version 字段，然后客户端1在第3步试图更新在第一步中查询到的数据时因version 已改变因此更新失败。
（图9-redis 乐观锁（watch））
　　redis 是通过watch 命令监控数据是否发生变化实现乐观锁的。如图9所示打开两个redis 客户端，客户端1对数据tom2 进行watch，打开事务更改tom1，tom2，客户端2更改客户端1中watch 的对象，步骤3客户端1提交事务由于watch 的对象被更改了，导致事务放弃执行。
　　3事务的ACID 性质
　　下面讨论下事务的ACID 性质。传统关系型数据库事务具备ACID 性质，这里不做详细讨论。
　　针对Redis 事务具有原子性（Atomicity），一致性（Consistency），和隔离性（Isolation），当redis 在持久化模式运行时，也具备持久性（Durability）。在场景1~3和乐观锁示例中redis 全部执行事务队列中的sql 语句即使其中sql存在操作对象错误，要么全部discard放弃执行，因此redis 事务具有原子性（Atomicity）。
　　redis 事务在执行过程中发生错误或进程被终结，都能保证数据的一致性（Consistency）。因为redis 使用单线程串行方式来执行事务的，在执行事务期间不会对事务进行中断（一致性），因此redis 事务也具有隔离性（Isolation）。redis 可以只将运行结果保存在内存中，但当redis 服务器使用AOF 持久化模式并appendfsync 设置为always 时，程序执行sql 后会调用sync 函数将数据保存到硬盘里，因此redis 事务也可以具有持久性（Durability）。
　　通过下表对redis 事务和关系型数据库事务做一个简单的总结。
关系型数据库（mysql）
start transaction命令
使用rollback命令可以回滚事务
不能回滚事务。但使用discard命令可以放弃事务queue中的sql
commit命令即使遇到sql语法错误也会提交事务
exec命令如果遇到sql语法错误会放弃事务中的sql
使用select ... for update实现悲观锁
通常使用version或时间戳来实现乐观锁
使用watch监控对象变化来实现乐观锁
原子性（Atomicity）
一致性（Consistency）
隔离性（Isolation）
持久性（Durability）
当redis服务器使用AOF持久化模式并appendfsync设置为always时具备
　　参考文档：
http://redis.io/topics/transactions
《redis设计与实现》黄健宏
　　本文作者：Tom（点融黑帮），现任点融Fin-Tech高级研发工程师，曾任职于IBM。
　　随着点融网新一轮融资，点融网即将开始大规模的扩张，需要各种优秀人才的加入，如果你觉得自己够优秀，欢迎加入我们！获取更多职位信息，请关注点融黑帮。
欢迎举报抄袭、转载、暴力色情及含有欺诈和虚假信息的不良文章。
请先登录再操作
请先登录再操作
微信扫一扫分享至朋友圈
搜狐公众平台官方账号
生活时尚&搭配博主 /生活时尚自媒体 /时尚类书籍作者
搜狐网教育频道官方账号
全球最大华文占星网站-专业研究星座命理及测算服务机构
主演：黄晓明/陈乔恩/乔任梁/谢君豪/吕佳容/戚迹
主演：陈晓/陈妍希/张馨予/杨明娜/毛晓彤/孙耀琦
主演：陈键锋/李依晓/张迪/郑亦桐/张明明/何彦霓
主演：尚格?云顿/乔?弗拉尼甘/Bianca Bree
主演：艾斯?库珀/ 查宁?塔图姆/ 乔纳?希尔
baby14岁写真曝光
李冰冰向成龙撒娇争宠
李湘遭闺蜜曝光旧爱
美女模特教老板走秀
曝搬砖男神奇葩择偶观
柳岩被迫成赚钱工具
大屁小P虐心恋
匆匆那年大结局
乔杉遭粉丝骚扰
男闺蜜的尴尬初夜
客服热线：86-10-
客服邮箱：Redis的事务功能详解
MULTI、EXEC、DISCARD和WATCH命令是Redis事务功能的基础。Redis事务允许在一次单独的步骤中执行一组命令，并且可以保证如下两个重要事项：
&Redis会将一个事务中的所有命令序列化，然后按顺序执行。Redis不可能在一个Redis事务的执行过程中插入执行另一个客户端发出的请求。这样便能保证Redis将这些命令作为一个单独的隔离操作执行。
& 在一个Redis事务中，Redis要么执行其中的所有命令，要么什么都不执行。因此，Redis事务能够保证原子性。EXEC命令会触发执行事务中的所有命令。因此，当某个客户端正在执行一次事务时，如果它在调用MULTI命令之前就从Redis服务端断开连接，那么就不会执行事务中的任何操作；相反，如果它在调用EXEC命令之后才从Redis服务端断开连接，那么就会执行事务中的所有操作。当Redis使用只增文件（AOF：Append-only File）时，Redis能够确保使用一个单独的write(2)系统调用，这样便能将事务写入磁盘。然而，如果Redis服务器宕机，或者系统管理员以某种方式停止Redis服务进程的运行，那么Redis很有可能只执行了事务中的一部分操作。Redis将会在重新启动时检查上述状态，然后退出运行，并且输出报错信息。使用redis-check-aof工具可以修复上述的只增文件，这个工具将会从上述文件中删除执行不完全的事务，这样Redis服务器才能再次启动。
从2.2版本开始，除了上述两项保证之外，Redis还能够以乐观锁的形式提供更多的保证，这种形式非常类似于“检查再设置”（CAS：Check And Set）操作。本文稍后会对Redis的乐观锁进行描述。
一、相关命令
用于标记事务块的开始。Redis会将后续的命令逐个放入队列中，然后才能使用EXEC命令原子化地执行这个命令序列。
这个命令的运行格式如下所示：
这个命令的返回值是一个简单的字符串，总是OK。
在一个事务中执行所有先前放入队列的命令，然后恢复正常的连接状态。
当使用WATCH命令时，只有当受监控的键没有被修改时，EXEC命令才会执行事务中的命令，这种方式利用了检查再设置（CAS）的机制。
这个命令的运行格式如下所示：
这个命令的返回值是一个数组，其中的每个元素分别是原子化事务中的每个命令的返回值。
当使用WATCH命令时，如果事务执行中止，那么EXEC命令就会返回一个Null值。
3. DISCARD
清除所有先前在一个事务中放入队列的命令，然后恢复正常的连接状态。
如果使用了WATCH命令，那么DISCARD命令就会将当前连接监控的所有键取消监控。
这个命令的运行格式如下所示：
这个命令的返回值是一个简单的字符串，总是OK。
当某个事务需要按条件执行时，就要使用这个命令将给定的键设置为受监控的。
这个命令的运行格式如下所示：
WATCH key [key ...]
这个命令的返回值是一个简单的字符串，总是OK。
对于每个键来说，时间复杂度总是O(1)。
5. UNWATCH
清除所有先前为一个事务监控的键。
如果你调用了EXEC或DISCARD命令，那么就不需要手动调用UNWATCH命令。
这个命令的运行格式如下所示：
这个命令的返回值是一个简单的字符串，总是OK。
时间复杂度总是O(1)。
二、使用方法
使用MULTI命令便可以进入一个Redis事务。这个命令的返回值总是OK。此时，用户可以发出多个Redis命令。Redis会将这些命令放入队列，而不是执行这些命令。一旦调用EXEC命令，那么Redis就会执行事务中的所有命令。
相反，调用DISCARD命令将会清除事务队列，然后退出事务。
以下示例会原子化地递增foo键和bar键的值：
正如从上面的会话所看到的一样，EXEC命令的返回值是一个数组，其中的每个元素都分别是事务中的每个命令的返回值，返回值的顺序和命令的发出顺序是相同的。
当一个Redis连接正处于MULTI请求的上下文中时，通过这个连接发出的所有命令的返回值都是QUEUE字符串（从Redis协议的角度来看，返回值是作为状态回复（Status Reply）来发送的）。当调用EXEC命令时，Redis会简单地调度执行事务队列中的命令。
三、事务内部的错误
在一个事务的运行期间，可能会遇到两种类型的命令错误：
一个命令可能会在被放入队列时失败。因此，事务有可能在调用EXEC命令之前就发生错误。例如，这个命令可能会有语法错误（参数的数量错误、命令名称错误，等等），或者可能会有某些临界条件（例如：如果使用maxmemory指令，为Redis服务器配置内存限制，那么就可能会有内存溢出条件）。
在调用EXEC命令之后，事务中的某个命令可能会执行失败。例如，我们对某个键执行了错误类型的操作（例如，对一个字符串（String）类型的键执行列表（List）类型的操作）。
可以使用Redis客户端检测第一种类型的错误，在调用EXEC命令之前，这些客户端可以检查被放入队列的命令的返回值：如果命令的返回值是QUEUE字符串，那么就表示已经正确地将这个命令放入队列；否则，Redis将返回一个错误。如果将某个命令放入队列时发生错误，那么大多数客户端将会中止事务，并且丢弃这个事务。
然而，从Redis 2.6.5版本开始，服务器会记住事务积累命令期间发生的错误。然后，Redis会拒绝执行这个事务，在运行EXEC命令之后，便会返回一个错误消息。最后，Redis会自动丢弃这个事务。
在Redis 2.6.5版本之前，如果发生了上述的错误，那么在客户端调用了EXEC命令之后，Redis还是会运行这个出错的事务，执行已经成功放入事务队列的命令，而不会关心先前发生的错误。从2.6.5版本开始，Redis在遭遇上述错误时，会采用先前描述的新行为，这样便能轻松地混合使用事务和管道。在这种情况下，客户端可以一次性地将整个事务发送至Redis服务器，稍后再一次性地读取所有的返回值。
相反，在调用EXEC命令之后发生的事务错误，Redis不会进行任何特殊处理：在事务运行期间，即使某个命令运行失败，所有其他的命令也将会继续执行。
这种行为在协议层面上更加清晰。在以下示例中，当事务正在运行时，有一条命令将会执行失败，即使这条命令的语法是正确的：
上述示例的EXEC命令的返回值是批量的字符串，包含两个元素，一个是OK代码，另一个是-ERR错误消息。客户端会根据自身的程序库，选择一种合适的方式，将错误信息提供给用户
需要注意的是，即使某个命令执行失败，事务队列中的所有其他命令仍然会执行 —— Redis不会停止执行事务中的命令。
再看另一个示例，再次使用telnet通信协议，观察命令的语法错误是如何尽快报告给用户的：
这一次，由于INCR命令的语法错误，Redis根本就没有将这个命令放入事务队列。
四、为什么Redis不支持回滚？
如果你具备关系型数据库的知识背景，你就会发现一个事实：在事务运行期间，虽然Redis命令可能会执行失败，但是Redis仍然会执行事务中余下的其他命令，而不会执行回滚操作，你可能会觉得这种行为很奇怪。
然而，这种行为也有其合理之处：
只有当被调用的Redis命令有语法错误时，这条命令才会执行失败（在将这个命令放入事务队列期间，Redis能够发现此类问题），或者对某个键执行不符合其数据类型的操作：实际上，这就意味着只有程序错误才会导致Redis命令执行失败，这种错误很有可能在程序开发期间发现，一般很少在生产环境发现。
Redis已经在系统内部进行功能简化，这样可以确保更快的运行速度，因为Redis不需要事务回滚的能力。
对于Redis事务的这种行为，有一个普遍的反对观点，那就是程序有可能会有缺陷（bug）。但是，你应当注意到：事务回滚并不能解决任何程序错误。例如，如果某个查询会将一个键的值递增2，而不是1，或者递增错误的键，那么事务回滚机制是没有办法解决这些程序问题的。请注意，没有人能解决程序员自己的错误，这种错误可能会导致Redis命令执行失败。正因为这些程序错误不大可能会进入生产环境，所以我们在开发Redis时选用更加简单和快速的方法，没有实现错误回滚的功能。
五、丢弃命令队列
DISCARD命令可以用来中止事务运行。在这种情况下，不会执行事务中的任何命令，并且会将Redis连接恢复为正常状态。示例如下所示：
六、通过CAS操作实现乐观锁
Redis使用WATCH命令实现事务的“检查再设置”（CAS）行为。
作为WATCH命令的参数的键会受到Redis的监控，Redis能够检测到它们的变化。在执行EXEC命令之前，如果Redis检测到至少有一个键被修改了，那么整个事务便会中止运行，然后EXEC命令会返回一个Null值，提醒用户事务运行失败。
例如，设想我们需要将某个键的值自动递增1（假设Redis没有INCR命令）。
首次尝试的伪码可能如下所示：
val = GET mykey
val = val + 1
SET mykey $val
如果我们只有一个Redis客户端在一段指定的时间之内执行上述伪码的操作，那么这段伪码将能够可靠的工作。如果有多个客户端大约在同一时间尝试递增这个键的值，那么将会产生竞争状态。例如，客户端-A和客户端-B都会读取这个键的旧值（例如：10）。这两个客户端都会将这个键的值递增至11，最后使用SET命令将这个键的新值设置为11。因此，这个键的最终值是11，而不是12。
现在，我们可以使用WATCH命令完美地解决上述的问题，伪码如下所示：
WATCH mykey
val = GET mykey
val = val + 1
SET mykey $val
由上述伪码可知，如果存在竞争状态，并且有另一个客户端在我们调用WATCH命令和EXEC命令之间的时间内修改了val变量的结果，那么事务将会运行失败。
我们只需要重复执行上述伪码的操作，希望此次运行不会再出现竞争状态。这种形式的锁就被称为乐观锁，它是一种非常强大的锁。在许多用例中，多个客户端可能会访问不同的键，因此不太可能发生冲突 —— 也就是说，通常没有必要重复执行上述伪码的操作。
七、WATCH命令详解
那么WATCH命令实际做了些什么呢？这个命令会使得EXEC命令在满足某些条件时才会运行事务：我们要求Redis只有在所有受监控的键都没有被修改时，才会执行事务。（但是，相同的客户端可能会在事务内部修改这些键，此时这个事务不会中止运行。）否则，Redis根本就不会进入事务。（注意，如果你使用WATCH命令监控一个易失性的键，然后在你监控这个键之后，Redis再使这个键过期，那么EXEC命令仍然可以正常工作。）
WATCH命令可以被调用多次。简单说来，所有的WATCH命令都会在被调用之时立刻对相应的键进行监控，直到EXEC命令被调用之时为止。你可以在单条的WATCH命令之中，使用任意数量的键作为命令参数。
当调用EXEC命令时，所有的键都会变为未受监控的状态，Redis不会管事务是否被中止。当一个客户单连接被关闭时，所有的键也都会变为未受监控的状态。
你还可以使用UNWATCH命令（不需要任何参数），这样便能清除所有的受监控键。当我们对某些键施加乐观锁之后，这个命令有时会非常有用。因为，我们可能需要运行一个用来修改这些键的事务，但是在读取这些键的当前内容之后，我们可能不打算继续进行操作，此时便可以使用UNWATCH命令，清除所有受监控的键。在运行UNWATCH命令之后，Redis连接便可以再次自由地用于运行新事务。
如何使用WATCH命令实现ZPOP操作呢？
本文将通过一个示例，说明如何使用WATCH命令创建一个新的原子化操作（Redis并不原生支持这个原子化操作），此处会以实现ZPOP操作为例。这个命令会以一种原子化的方式，从一个有序集合中弹出分数最低的元素。以下源码是最简单的实现方式：
WATCH zset
element = ZRANGE zset 0 0
ZREM zset element
如果伪码中的EXEC命令执行失败（例如，返回Null值），那么我们只需要重复运行这个操作即可。
八、Redis脚本和事务
根据定义，Redis脚本也是事务型的。因此，你可以通过Redis事务实现的功能，同样也可以通过Redis脚本来实现，而且通常脚本更简单、更快速。
由于Redis从2.6版本才开始引入脚本特性，而事务特性是很久以前就已经存在的，所以目前的版本才有两个看起来重复的特性。但是，我们不太可能在短时间内移除对事务特性的支持。因为，即使不用求助于Redis脚本，用户仍然能够规避竞争状态，这从语义上来看是适宜的。还有另一个更重要的原因，Redis事务特性的实现复杂度是最小的。
但是，在相当长的一段时间之内，我们不大可能看到整个用户群体都只使用Redis脚本。如果发生这种情况，那么我们可能会废弃，甚至最终移除Redis事务。
阅读(...) 评论()}