Redis-事务和锁机制

1、什么是事务？

简单地说是一系列redis命令的集合。事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序执行。在执行时不会被其他客户端发来的命令请求打断。

Redis事务的主要作用是串联多个命令，防止别的命令插入打断。

2、事务的用法

事务通过MULTI、EXEC、DISCARD和WATCH四个原语实现的。

MULTI：开启一个事务，返回OK，之后输入的命令都会依次进入命令队列中，不会执行。直到输入EXEC后。

EXEC：依次执行命令队列中的命令。

DISCARD：调用DISCARD客户端可以清空事务队列，并放弃执行事务。

WATCH：在执行MULTI之前，先执行watch key [key2],可以监视一个或者多个key，如果在事务执行EXEC之前这些key被其他命令改动，那么事务将会被打断。

UNWATCH：取消对key的监视。

演示几个情景：

MULTI  ------->  EXEC:

正常执行：

MULTI   ---------> DISCARD

当执行 DISCARD 命令时，事务会被放弃，事务队列会被清空，并且客户端会从事务状态中退出

3、事务内部的错误处理

一个事务的运行期间分为两种情况：

1）语法错误：组队中某个命令出现了报告错误，（已经提示错误）再执行时整个的所有队列都会被取消。

在执行EXEC命令之前，客户端可以检查放入队列的命令的返回值，返回值是QUEUE字符，表示正确地将这命令放入队列中，否则Redis返回一个错误。如果是放入队列发生错误，那么中止事务，并丢弃这个事务。

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

这个时候我们不禁就会问一下Redis 是单线程，为何却需要事务处理并发问题。搜索执行命令都是one by one也是会出现多并发问题，就那简单的一张银行卡被多个人绑定，并同时参加双十一购买商品。

4、事务冲突问题

一张银行卡被三个人绑定，在双十一用于购物。

甲：请求支付8000、乙：请求支付5000、丙：请求支付1000，而在银行卡中只有10000。

两种解决这个问题：

1）悲观锁

悲观锁(Pessimistic Lock), 顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，

所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。等使用完锁解开其他人才可以使用。

传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。

2）乐观锁

乐观锁(Optimistic Lock), 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，

但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。

乐观锁适用于多读的应用类型，这样可以提高吞吐量。Redis就是利用这种check-and-set机制实现事务的

演示乐观锁

在演示乐观锁时，使用到WATCH，对key进行监视。

案例场景：假如买票，当前只有一张票，如果在买票过程中，我在MULTI之后，还未EXEC，票就被人买走了，这时ticket就变成0，但是你不可以在支付钱，因为票已经买完了，不可以ticket变成-1吧。

5、Redis事务三特性

    1）单独的隔离操作

事务所有的命令都是序列化的、按顺序地执行。在执行过程不会被其他事务打断。

    2）没有隔离级别的概念

队列中的命令没有提交之前，其实没有被执行。

    3）不保证原子性

事务中如果又一条命令在执行时失败，其后面的命令仍然可以被执行，没有回滚操作。