redis对事物是半支持
下面看一下Redis对事务错误处理
语法错误 就像上面的例子一样，语法错误表示命令不存在或者参数错误
这种情况需要区分Redis的版本，Redis 2.6.5之前的版本会忽略错误的命令，执行其他正确的命令，2.6.5之后的版本会忽略这个事务中的所有命令，都不执行，就比如上面的例子(使用的Redis版本是2.8的)
运行错误 运行错误表示命令在执行过程中出现错误，比如用GET命令获取一个散列表类型的键值。
这种错误在命令执行之前Redis是无法发现的，所以在事务里这样的命令会被Redis接受并执行。如果食物里有一条命令执行错误，其他命令依旧会执行（包括出错之后的命令）。比如下例：
Redis中的事务并没有关系型数据库中的事务回滚(rollback)功能，因此使用者必须自己收拾剩下的烂摊子。不过由于Redis不支持事务回滚功能，这也使得Redis的事务简洁快速。
所以,对于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的事务里面，采用的是乐观锁，主要是为了提高性能，减少客户端的等待。由几个命令构成：WATCH, UNWATCH, MULTI, EXEC, DISCARD。 通过WATCH，可以实现CAS操作。使用WATCH监听一些键，然后去检查键的值，然后根据键的值来决定是否还需要进行MULTI，如果键的值被改了，则重新。（因为有可能在执行WATCH前，键的值被改了，所以需要先WATCH，然后再作判断）。在执行MULTI命令后，如果中途WATCH的键的值被修改了，后续再执行EXEC时，整个事务都会被终止。
CAS使用示例： 假设存在一个String类型的状态值,state，需要对其进行CAS操作：
WATCH stat\n value = GET state\n if value == \n UNWATCH stat\n Return false\n MULT\n SET state \n result = EXE\n if result == succes\n return true\n return false;
原理
Redis事务实现原理
通过上述的基本应用可以知道，Redis是通过WATCH命令，来保证当前事务的数据是否被修改过，如果被修改了，则整个事务会中止，不再执行。那么，Redis在实现的时候，会保存对应的watch key，然后中途如果该Key被修改了，则会将对应的所有客户端的标志位都置为CLIENT_DIRTY_CAS，表示数据被修改，后续执行EXEC的时候则会被中断，从而实现事务。而UNWATCH命令则是从保存的watch_keys里面移除。MULTI命令仅仅将客户端的标志位flags置为CLIENT_MULTI，表示处于MULTI状态，该状态下，后续的命令（除了MULTI/WATCH/DISCARD/EXEC）外，其它命令都会被保存到一个列表里面，直到EXEC或者DISCARD命令执行。如果中途出现了语法错误之类的命令，则会将flags置为CLIENT_DIRTY_EXEC。后续执行EXEC时，如果flags存在CLIENT_DIRTY_CAS或者CLIENT_DIRTY_EXEC，则整个事务会被中止，不执行任何命令。
ACID分析
针对Redis的事务实现，对于ACID，个人认为，对于Atomicity和Durability以及Consistency，Redis是不满足的。为什么会对ACID进行分析呢，一部分原因是为了作对比学习，另一部分是因为《Redis设计与实现》19章事务ACID性质里面提到了一些观点，个人不太认同，所以进行了一些对比。
Atomicity
指的是要么不执行，要么全部执行。当其中一部分执行了，但是另外一部分没有执行，那么作为整个事务，是全部要回滚，都不执行的，而Redis在执行过程中，如果出现操作和类型不一致，则会导致一部分执行，而一部分错误的情况，即不满足原子性。当然，除去部分失误外，还是能够保证原子性的，但是这并不是严格的原子性要求。
Durability
持久性，事务提交后，无论出现任何情况，包括系统断电之类的，重启后都是可以恢复的。对于Redis来说，即使开启了AOF以及设置为always，也存在命令执行一部分后，系统宕机而导致数据不一致的情况，不能恢复。一般都是通过write-ahead-logging来实现的，即事先写日志，而Redis是边执行边写日志。
Consistency
一致性，指从一个有效的状态转到另一个有效的状态，不满足上述的两个条件，也无法保存一致性，即会出现中间状态。比如从一个人的账户转到另外一个人上面，执行了转出，但是没有执行转入的时候宕机了，就会导致数据的不一致。
Isolation
隔离性，在多个事务并发的情况下，事务之间不会被影响。对于Redis来说，事务的执行是串行的，中途不会插入其它命令的执行，所以是满足隔离性的。
WATCH命令实现
WATCH监听Key，首先就要有地方保存监听的Key，Redis针对不同的客户端，会在客户端的结构体里面维护一个WATCH监听Key的列表，以及在Server里面维护一个全局的哈希表，Key为被监听的Key，Value则为一个链表，里面保存了所有监听该Key的客户端。如下图：
当执行WATCH account时，则首先会判断该Key是否已在客户端里面，如果存在，则直接返回，否则加入到客户端对应的watched_keys列表里面，然后再将其加入到对应DB的watched_keys字典表里面，Key为 account，Value则为该客户端。
