Redis---事务之日常学习

Redis 支持事务 但只是部分支持并没有强一致性。

可以一次执行多个命令，本质是一组命令的集合，一个事务中的所有命令都会序列化，按顺序的串行执行，执行而不会被其他命令插入，不许加塞
一个队列中，一次性，顺序性，排他性的执行一系列命令

常用命令

discard ：取消事务，放弃执行事务块内的所有命令
exec ：执行事务块内的命令
unwatch：取消watch命令对所有key的监控
watch key：监控一个或者多个key，如果在事务执行之前这个或者这些key被其他命令所 改动那么事务将被打断，
multi：标记一个事务块的开始
incr：数据加1，受数据类型限制 int才可使用

正常执行

放弃事务

全体连坐

冤头债主

watch监控

1.创建两个值 myNum 我的数字 useNum使用掉的数字

2.使用watch myNum 命令,对myNum进行监控，使用multi启动事务，decrby myNum 使用掉20个数字，incrby 添加20个数字。exec执行事务内的所有命令。完成监控、事务的操作。
如图，并没有报错。

3.先使用watch myNum命令，对myNum进行监控。然后在一个新的窗口执行 set myNum 300命令。对其进行修改。如4图右侧部分。接着在回到3图的窗口继续往下编写命令。执行exec后会发现执行失败。那是因为watch监控发现了myNum被修改过，所以不允许修改。

4.当watch发现数据没有发生变更的时候，就会执行成功。

悲观锁：

悲观锁（pessimistic lock ） 顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次去拿数据的时候都会上锁。
这样别人想拿这个数据就会block直到他拿到锁，传统的关系型数据库里就用了很多这种锁机制，必须行锁表锁读锁写锁。
都是在操作之前先锁上，（一般可以再深夜备份的时候锁一下）

乐观锁：

乐观锁（optimistic lock），顾名思义，就是很乐观。每次去拿数据的时候都会认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下，在此期间别人有没有在去跟新这个数据，可以适用版本号的机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量。

乐观策略：

提交版本必须大于记录当前版本才能执行更新。

CAS：

两种情况：无塞篡改 有塞篡改 （加塞的要重新去抓新的数据）
一旦执行Exec或者 UNwatch 之前加的监控锁都会被取消掉。

小结：

watch指令，类似乐观锁，事务提交时，如果key的值被别的客户端改变，
比如某个list已经被别的客户端push/pop过了，整个事务对列都不会被执行。
通过watch命令在事务执行之前监控了这个key，倘若在挖watch之后有任何key的值发生了变化。
exec命令执行的事务都会被放弃。同时返回Nullmulti-bulk应答以前通知调用者事务执行失败。

三阶段

开启： 以multi开始一个事务
入列：将多个命令入列到事务中，接到这些命令并不会立即执行，而是放到等待执行的事务对列中
执行：由exec命令触发事务

三特征：

1. 单独的隔离操作：事务中的所有的命令都会序列化、按顺序的执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
2. 没有隔离级别的概念：列队中的命令没有提交之前都不会实际的被执行，因为事务提交前任何执行都不会被实际执行，也不存在“事务内的查询要看到事务里的更新，在事务外查询不能看到”这个让人万分头痛的问题。
3. 不保证原子性：redis通一个事务中如果有一条命令执行失败，其后的命令耐燃会被执行，没有回滚。