redis事物

1. 是什么：
   
   可以一次执行多个命令，本质是一组命令的集合。一个事务中的
   所有命令都会序列化，按顺序地串行化执行而不会被其它命令插入，不许加塞
   
    
2. 能干嘛：
   
   一个队列中，一次性、顺序性、排他性的执行一系列命令
    
3. 常用命令：
    

   MULTI
   
   MULTI
   
   标记一个事务块的开始。
   
   事务块内的多条命令会按照先后顺序被放进一个队列当中，最后由 EXEC 命令原子性(atomic)地执行。
   
   可用版本：
   >= 1.2.0
   
   时间复杂度：
   O(1)。
   
   返回值：
   总是返回 OK 。
   
   redis> MULTI            # 标记事务开始
   OK
   
   redis> INCR user_id     # 多条命令按顺序入队
   QUEUED
   
   redis> INCR user_id
   QUEUED
   
   redis> INCR user_id
   QUEUED
   
   redis> PING
   QUEUED
   
   redis> EXEC             # 执行
   1) (integer) 1
   2) (integer) 2
   3) (integer) 3
   4) PONG
   
   
   EXEC
   
   EXEC
   
   执行所有事务块内的命令。
   
   假如某个(或某些) key 正处于 WATCH 命令的监视之下，且事务块中有和这个(或这些) key 相关的命令，那么 EXEC 命令只在这个(或这些) key 没有被其他命令所改动的情况下执行并生效，否则该事务被打断(abort)。
   
   可用版本：
   >= 1.2.0
   
   时间复杂度：
   事务块内所有命令的时间复杂度的总和。
   
   返回值：
   事务块内所有命令的返回值，按命令执行的先后顺序排列。
   当操作被打断时，返回空值 nil 。
   # 事务被成功执行
   
   redis> MULTI
   OK
   
   redis> INCR user_id
   QUEUED
   
   redis> INCR user_id
   QUEUED
   
   redis> INCR user_id
   QUEUED
   
   redis> PING
   QUEUED
   
   redis> EXEC
   1) (integer) 1
   2) (integer) 2
   3) (integer) 3
   4) PONG
   
   
   # 监视 key ，且事务成功执行
   
   redis> WATCH lock lock_times
   OK
   
   redis> MULTI
   OK
   
   redis> SET lock "huangz"
   QUEUED
   
   redis> INCR lock_times
   QUEUED
   
   redis> EXEC
   1) OK
   2) (integer) 1
   
   
   # 监视 key ，且事务被打断
   
   redis> WATCH lock lock_times
   OK
   
   redis> MULTI
   OK
   
   redis> SET lock "joe"        # 就在这时，另一个客户端修改了 lock_times 的值
   QUEUED
   
   redis> INCR lock_times
   QUEUED
   
   redis> EXEC                  # 因为 lock_times 被修改， joe 的事务执行失败
   (nil)
   
   
   DISCARD
   
   可用版本： >= 2.0.0
   时间复杂度： O(1)。
   取消事务，放弃执行事务块内的所有命令。
   
   如果正在使用 WATCH 命令监视某个(或某些) key，那么取消所有监视，等同于执行命令 UNWATCH 。
   
   返回值
   
   总是返回 OK 。
   
   代码示例
   
   redis> MULTI
   OK
   
   redis> PING
   QUEUED
   
   redis> SET greeting "hello"
   QUEUED
   
   redis> DISCARD
   OK
   
   
   WATCH
   
   WATCH key [key …]
   
   监视一个(或多个) key ，如果在事务执行之前这个(或这些) key 被其他命令所改动，那么事务将被打断。
   
   可用版本：
   >= 2.2.0
   
   时间复杂度：
   O(1)。
   
   返回值：
   总是返回 OK 。
   
   redis> WATCH lock lock_times
   OK
   
   
   UNWATCH
   
   UNWATCH
   
   取消 WATCH 命令对所有 key 的监视。
   
   如果在执行 WATCH 命令之后， EXEC 命令或 DISCARD 命令先被执行了的话，那么就不需要再执行 UNWATCH 了。
   
   因为 EXEC 命令会执行事务，因此 WATCH 命令的效果已经产生了；而 DISCARD 命令在取消事务的同时也会取消所有对 key 的监视，因此这两个命令执行之后，就没有必要执行 UNWATCH 了。
   
   可用版本：
   >= 2.2.0
   
   时间复杂度：
   O(1)
   
   返回值：
   总是 OK 。
   
   redis> WATCH lock lock_times
   OK
   
   redis> UNWATCH
   OK

4. 悲观锁：
   
   悲观锁(Pessimistic Lock), 顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁
   
    
5. 乐观锁：
    

   
    乐观锁(Optimistic Lock), 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量，
   乐观锁策略:提交版本必须大于记录当前版本才能执行更新
    

6. redis事物的三个阶段：
   
   开启：以MULTI开始一个事务
   
   入队：将多个命令入队到事务中，接到这些命令并不会立即执行，而是放到等待执行的事务队列里面
   
   执行：由EXEC命令触发事务
   
    
7. 特性：
   
   单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
   
   没有隔离级别的概念：队列中的命令没有提交之前都不会实际的被执行，因为事务提交前任何指令都不会被实际执行，
   也就不存在”事务内的查询要看到事务里的更新，在事务外查询不能看到”这个让人万分头痛的问题
   
   不保证原子性：redis同一个事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚