Redis学习：事务和锁机制

​ Redis事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地进行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。

​ Redis事务的主要作用就是串联多个命令防止别的命令插队。

Multi、Exec、discard

​ 从输入Multi命令开始，输入的命令都会依次进入命令队列中，但不会执行，直到输入Exec后，Redis会将之前的命令队列中的命令依次执行。

​ 组队的过程中可以通过discard来放弃组队。

事务的错误处理

1.组队中某个命令出现了报告错误，执行时整个的所有队列都会被取消

127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)> set a1 v1
QUEUED
127.0.0.1:6379(TX)> set a2 v2
QUEUED
127.0.0.1:6379(TX)> set a3
(error) ERR wrong number of arguments for 'set' command
127.0.0.1:6379(TX)> exec
(error) EXECABORT Transaction discarded because of previous errors.
127.0.0.1:6379>

2.如果执行阶段某个命令报出了错误，则只有报错的命令不会被执行，而其他的命令都会执行，不会回滚。

127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)> set b1 v1
QUEUED
127.0.0.1:6379(TX)> incr b1
QUEUED
127.0.0.1:6379(TX)> set b2 v2
QUEUED
127.0.0.1:6379(TX)> exec
1) OK
2) (error) ERR value is not an integer or out of range
3) OK
127.0.0.1:6379>

悲观锁

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

乐观锁

​ 乐观锁（Optimistic Lock），顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制，乐观锁适用于多读的应用类型，这样可以提高吞吐量。Redis就是利用这种check-and-set机制实现事务的。

WATCH key [key …]

​ 在执行multi之前，先执行watch key1 [key2]，可以监视一个（或多个）key，如果在事务执行之前这个key被其他命令所改动，那么事务会被打断。

案例：先创建一个key：balance，对它进行监视，开启事务进行操作，同时其他链接对此key进行操作，执行原先事务会被打断

#窗口1：
127.0.0.1:6379> set balance 100			#第一步
OK
127.0.0.1:6379> incrby balance 10		#第四步
(integer) 110
127.0.0.1:6379>

#窗口2：
127.0.0.1:6379> watch balance			#第二步
OK
127.0.0.1:6379> multi					#第三步
OK
127.0.0.1:6379(TX)> set c1 v1			#第五步...
QUEUED
127.0.0.1:6379(TX)> incrby balance 10
QUEUED
127.0.0.1:6379(TX)> set c2 v2
QUEUED
127.0.0.1:6379(TX)> exec
(nil)									#因为监视key改变，导致事务失败
127.0.0.1:6379> 

Redis事务三特性

• 单独的隔离操作

  ​ 事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送过来的命令请求所打断。

• 没有隔离级别的概念

  ​ 队列中的命令没有提交之前都不会实际被执行。

• 不保证原子性

  ​ 事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚。