介绍
- redis的目标的是： 简洁，高效，由于事务本身就是一个很复杂的东西，所有我们不能把事务做的太复杂。
DISCARD取消事务，放弃执行事务块内的所有命令。EXEC执行所有事务块内的命令。MULTI标记一个事务块的开始。UNWATCH取消 WATCH 命令对所有 key 的监视。-
WATCHkey [key ...] 监视一个(或多个) key ，如果在事务执行之前这个(或这些) key 被其他命令所改动，那么事务将被打断。MULTI 和 EXEC
127.0.0.1:6379> multi
OK
127.0.0.1:6379> lpush fruits orange
QUEUED
127.0.0.1:6379> lpush fruits nut
QUEUED
127.0.0.1:6379> lpush fruits apple
QUEUED
127.0.0.1:6379> exec
1) (integer) 1
2) (integer) 2
3) (integer) 3
我们发现命令是一起执行的，如果说我的某一条命令执行失败，会回滚吗?
答案是不会回滚。看看下面的原子性。
原子性
事务的原子性是指要么事务全部成功，要么全部失败，那么 Redis 事务执行是原子性的么？ 下面我们来看一个特别的例子。
> multi
OK
> set books iamastring # 执行成功
QUEUED
> incr books # 执行失败
QUEUED
> set poorman iamdesperate # 执行成功
QUEUED
> exec
1) OK
2) (error) ERR value is not an integer or out of range
3) OK
> get books
"iamastring"
> get poorman
"iamdesperate
上面的例子是事务执行到中间遇到失败了，因为我们不能对一个字符串进行数学运算，事务在遇到指令执行失败后，后面的指令还继续执行，所以 poorman 的值能继续得到设置。
到这里，你应该明白 Redis 的事务根本不能算「原子性」，而仅仅是满足了事务的「隔离性」，隔离性中的串行化——当前执行的事务有着不被其它事务打断的权利。
Watch
我在执行lpush的时候，lpush被其他人改变了。
需求：在写multi的时候，不可以有其他的命令更改 “队列”中的集合。
出现并发问题，因为有多个客户端会并发进行操作。我们可以通过 Redis 的分布式锁来避免冲突，这是一个很好的解决方案。分布式锁是一种悲观锁，那是不是可以使用乐观锁的方式来解决冲突呢？
Redis 提供了这种 watch 的机制，它就是一种乐观锁。有了 watch 我们又多了一种可以用来解决并发修改的方法。 watch 的使用方式如下：
127.0.0.1:6379> watch msg
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set msg "hello wolrd"
QUEUED
127.0.0.1:6379> exec
(nil)
127.0.0.1:6379> get msg
"12345"
127.0.0.1:6379>
注意事项
Redis 禁止在 multi 和 exec 之间执行 watch 指令，而必须在 multi 之前做好盯住关键变量，否则会出错。
.net操练，在StackExchange.Redis又该怎么做？
更复杂的事实是StackExchange.Redis使用的是多路复用器的方式。
我们不能只让并发调用方发布 WATCH / UNWATCH / MULTI / EXEC / DISCARD：这应该是混合在一起的。所以一个额外的抽象被给出：另外会让使事情更简单准确：约束。约束是预定义测试包括 WATCH 某种类型的测试并对结果进行检查。如果所有的约束都通过了，那么要么是以 MULTI / EXEC 发布(从事务开始，到执行整个事务块)；要么是以 UNWATCH 发布(取消 WATCH 命令对所有 key 的监视)。阻止命令于其它调用方被混合在一起；所以例子可以是：
注意：从 CreateTransaction 返回的对象最后都是调用异步方法来执行命令(Execute方法最终也是调用ExecuteAsync，具体可以看源码)：由于不知道每个操作的结果，除非在 Execute 或 ExecuteAsync 操作完成后。如果操作没有被执行，所有的Task 将被标记为取消，否则在命令执行后你可以获取每个正常的结果。
static void Transaction()
{
using (ConnectionMultiplexer redis = ConnectionMultiplexer.Connect("localhost:6379"))
{
IDatabase db = redis.GetDatabase();
ITransaction tran = db.CreateTransaction();
//为该事务添加先决条件
//强制指定指定的哈希字段不能存在。
tran.AddCondition(Condition.HashNotExists("transactionDemo", "UniqueID"));
tran.HashSetAsync("transactionDemo", "UniqueID","Unnn");
bool committed = tran.Execute();
Console.WriteLine(committed); //第1次执行,true，因为不存在，后面执行false，因为存在
}
}
通过 When 的内置操作
还应该注意的是，Redis已经为我们预料到了许多常见的场景(特别是：key/hash的存在，就像上面一样)，还有单操作(single-operation)原子命令的存在。 通过 When 来访问，所以前面的示例也可以这样来实现：
var newId = CreateNewId();
bool wasSet = db.HashSet(custKey, "UniqueID", newId, When.NotExists);
注意：When.NotExists 会使用命令 HSETNX 而不会使用 HSET
HSETNX：如果字段已经存在于哈希表中，操作无效。