1.关系型数据库的事务
事务是应用程序中一系列严密的操作，所有操作必须成功完成，否则在每个操作中所作的所有更改都会被撤消。
Atomic（原子性）：
一个事务（transaction）中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。
Consistency（一致性）：
事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。
Isolation（隔离性）：
一个事务的执行不能其它事务干扰。事务允许多个用户对同一个数据进行并发访问，而不破坏数据的正确性和完整性。
Durability（持久性）：
也一个事务一旦提交，它对数据库中的数据的改变就应该是永久性的。接下来的其它操作或故障不应该对其执行结果有任何影响。
2.Redis的事务
Redis对事务 的支持比较简单。
Redis 是单进程程序，并且它保证在执行事务时，不会对事务进行中断，事务可以运行直到执 行完所有事务队列中的命令为止。因此，Redis 的事务支持隔离性。
实现事务的命令：
MULTI 标记一个事务块的开始。
EXEC 执行所有事务块内的命令。
DISCARD 取消事务，放弃执行事务块内的所有命令。
UNWATCH 取消 WATCH 命令对所有 key 的监视。
WATCH key [key ...]
监视一个(或多个) key ，如果在事务执行之前这个(或这些) key 被其他命令所改动，那么事务将被打断。
redis事务不支持回滚。
3.Redis事务中的乐观锁
Redis使用 check-and-set 操作实现乐观锁。
WATCH 命令可以为 Redis 事务提供 check-and-set （CAS）行为。
类似Java中的CompareAndSet机制，被 WATCH 的键会被监视，并会发觉这些键是否被改动过了。
如果有至少一个被监视的键在 EXEC 执行之前被修改了， 那么整个事务都会被取消， EXEC 返回空多条批量回复（null multi-bulk reply）来表示事务已经失败。
举个例子， 假设我们需要原子性地为某个值进行增 1 操作（假设 INCR 不存在）。
首先我们可能会这样做：
|
1
2
3
|
val
=
GET mykey
val
=
val
+
1
SET
mykey $val
|
上面的这个实现在只有一个客户端的时候可以执行得很好。 但是， 当多个客户端同时对同一个键进行这样的操作时， 就会产生竞争条件。
举个例子， 如果客户端 A 和 B 都读取了键原来的值， 比如 10 ， 那么两个客户端都会将键的值设为 11 ， 但正确的结果应该是 12 才对。
有了 WATCH ， 我们就可以轻松地解决这类问题了：
|
1
2
3
4
5
6
7
|
WATCH mykey
val
=
GET mykey
val
=
val
+
1
MULTI
SET
mykey $val
EXEC
|
使用上面的代码， 如果在 WATCH 执行之后， EXEC 执行之前， 有其他客户端修改了 mykey 的值， 那么当前客户端的事务就会失败。 程序需要做的， 就是不断重试这个操作， 直到没有发生碰撞为止。
乐观锁是一种非常强大的锁机制，在很多地方都有应用。 Redis中大多数情况下， 不同的客户端会访问不同的键， 碰撞的情况一般都很少， 所以通常并不需要进行重试。
