redi事务简单介绍

　我们都知道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：

 

2. watch

　 不知道你看完multi后面的三条set命令之后，有没有一种心虚的感觉，怎么说呢，就是只要命令是正确的，redis保证会一并执行，誓死完成

任务，虽然说命令是一起执行的，但是谁可以保证我在执行命令的过程中，其他client不会修改这些值呢？？？如果修改了这些值，那我的exec

还有什么意义呢？？？没关系，这种烂大街的需求，redis怎可能袖手旁观？？？这里的watch就可以助你一臂之力。

WATCHWATCH key [key ...]监视一个(或多个) key ，如果在事务执行之前这个(或这些) key 被其他命令所改动，那么事务将被打断。

　上面就是redis手册中关于watch的解释，使用起来貌似很简单，就是我在multi之前，用watch去监视我要修改的key，如果说我在exec之前，

multi之后的这段时间，key被其他client修改，那么exec就会执行失败，返回（nil），就这么简单，我还是来举个例子：

 

注意的地方：

Redis与 mysql事务的对比

 

 

Mysql

Redis

开启

start transaction

muitl

语句

普通sql

普通命令

失败

rollback 回滚

discard 取消

成功

commit

exec

 

注: rollback与discard 的区别

如果已经成功执行了2条语句, 第3条语句出错.

Rollback后,前2条的语句影响消失.

Discard只是结束本次事务,前2条语句造成的影响仍然还在

 

注:

在mutil后面的语句中, 语句出错可能有2种情况

1: 语法就有问题,

这种,exec时,报错, 所有语句得不到执行

 

2: 语法本身没错,但适用对象有问题. 比如 zadd 操作list对象

Exec之后,会执行正确的语句,并跳过有不适当的语句.

 

(如果zadd操作list这种事怎么避免? 这一点,由程序员负责)