1.事务简介

mysql中事务四大特性，原子性，隔离性，持久性，一致性。

可以一次执行多个命令，本质是一组命令的集合。一个事务中的所有命令都会序列化，按顺序地串行化执行而不会被其它命令插入，不许加塞单独的隔离的操作。

MULTI、EXEC、DISCARD、WATCH。这四个指令构成了 redis 事务处理的基础。

2.Redis事务处理流程

1.MULTI 用来组装一个事务；将命令存放到一个队列里面
2.EXEC 用来执行一个事务；//commit
3.DISCARD 用来取消一个事务；//rollback
4.WATCH 用来监视一些 key，一旦这些 key 在事务执行之前被改变，则取消事务的执行。

案例：

有关事务，经常会遇到的是两类错误：

1.调用 EXEC 之前的错误

“调用 EXEC 之前的错误”，有可能是由于语法有误导致的，也可能时由于内存不足导致的。只要出现某个命令无法成功写入缓冲队列的情况，redis 都会进行记录，在客户端调用 EXEC 时，redis 会拒绝执行这一事务。

2.调用 EXEC 之后的错误?

而对于“调用 EXEC 之后的错误”，redis 则采取了完全不同的策略，即 redis 不会理睬这些错误，而是继续向下执行事务中的其他命令。这是因为，对于应用层面的错误，并不是 redis 自身需要考虑和处理的问题，所以一个事务中如果某一条命令执行失败，并不会影响接下来的其他命令的执行。

?3.Redis事务冲突

双十一去购物的时候使用同一张银行卡去付款

一个请求想给金额减8000

一个请求想给金额减5000

一个请求想给金额减1000

解决方案：

悲观锁

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

乐观锁

version 1

查余额 10000 version：1

10000>8000 -8000 update uuuu set money-=8000 where version=1 1.1

10000 -5000 UPDATE uuuuu SET money-=5000 WHERE VERSION=1

2000 2000>1000 UPDATE uuuu SET money-=1000 WHERE VERSION=1.1 1.2

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

?4.Watch

“WATCH”可以帮我们实现类似于“乐观锁”的效果，即 CAS（check and set）。

WATCH 本身的作用是“监视 key 是否被改动过”，而且支持同时监视多个 key，只要还没真正触发事务，WATCH 都会尽职尽责的监视，一旦发现某个 key 被修改了，在执行 EXEC 时就会返回 nil，表示事务无法触发。

127.0.0.1:6379> set age 23
OK
127.0.0.1:6379> watch age //开始监视 age
OK
127.0.0.1:6379> set age 24 //在 EXEC 之前，age 的值被修改了
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set age 25
QUEUED
127.0.0.1:6379> get age
QUEUED
127.0.0.1:6379> exec //触发 EXEC
(nil) //事务无法被执行

事务回滚：
192.168.109.34:6379> multi
OK
192.168.109.34:6379> set testsy testq
QUEUED
192.168.109.34:6379> set testsy2 test2
QUEUED
192.168.109.34:6379> discard
OK