redis系列（11）-- 高级话题之redis事务（实现部分）

前言：废话不说，上手就干
1、正常执行事务
事务的执行步骤：首先开启事务，其次向事务队列中加入命令，最后执行事务提交
1）mulit：用mulit命令告诉redis，接下来要执行的命令你先不要执行，而是把他们暂时存起来（开启事务）
2）sadd address beijing 第一条命令进入等待队列（命令入队）
3）sadd address shanghai 第二条命令进入等待队列（命令入队）
4) exce 告知redis执行前面发送的两条命令

2、事务执行exec之前，入队命令错误（语法错误；严重错误导致服务器不能正常工作（例如内存不足）），放弃事务。
执行事务步骤：
1）mulit正常命令
2）sadd key value 正常命令
3）sadd key value 正常命令
4）sadd key value 错误命令
5）exec 无法执行事务，那么两条正确的命令也不执行，所有key的值不会设置成功

结论：事务执行exec之前，入队命令错误，事务终止，取消，不执行。
3、事务执行exec命令后，执行队列命令，命令执行错误，事务提交
执行步骤：
1）multi正常命令
2）set name zhangshan 正常命令
3）lpop name 正常命令，语法没有错误，执行命令时才会有错误
4）exec 正常执行，发现错误可以在事务提交前放弃事务，执行discard

上面的例子中，lpop name 这条命令是错误的，但命令进入队列，命令语法没有错误，lpop是列表类型的命令，不能操作字符串类型的数据，exec命令后执行lpop name出错，但事务中的其他命令依然执行。
结论：在exec执行后的所产生的错误，即时事务中有某个/某些命令执行时产生了错误，事务中的其他命令依然会继续执行。
redis在事务失败时不进行回滚，而是继续执行余下的命令
redis这种设计原则是：redis命令只会因为错误的语法而失败（这些问题不能在入队时发现），或是命令用在了错误类型的键上面，失败的命令并不是redis导致，而是由编程错误造成的，这样的错误应该在开发的过程中被发现，生产环境中不应该出现语法错误，就是在程序的运行环境中不应该出现语法错误。而redis能够保证正确的命令一定会被执行，再者不需要对回滚进行支持，所以redis的内部可以保持简单且快速。
4、放弃事务
执行步骤
1）multi 开启事务
2）set name zhangshan
3）set age 20
4）discard 放弃事务，则命令对垒不会被执行

5、redis的watch机制
1）rediswatch机制原理
watch机制：使用watch监视一个或多个key，跟踪key的value修改情况，如果有key的value值在事务exec执行之前被修改了，整个事务取消，exec返回提示信息，表示事务已经失败。
watch机制使的事务exec变得有条件，事务只有在被watch的key没有被修改的前提下才能执行，不满足条件，事务被取消，使用watch监视了一个带过期时间的键，那么即时这个键过期了，事务仍然可以正常执行
大多数情况下，不同的客户端会访问不同的键，相互竞争同一key的情况一般都很少，乐观锁能够以很好的性能解决数据冲突的问题
2）何时取消key的监视？
a.watch命令可以被调用多次，对键的监视从watch执行之后开始生效，知道调用exec为止，不管事务是否执行成功，对所有键的监视都会被取消
b.当客户端断开连接时，该客户端对键的监视也会被取消
c.unwatch命令可以手动取消对所有键的监视
6、watch的事例
执行步骤：首先启动redis，在开启两个客户端连接，分别称之为A客户端和B客户端
A客户端（红色）：watch某个key，同时执行事务

B客户端（紫色）：对A客户端watch的key修改其value值

1）在A客户端使用watch监视为age的key
2）在A客户端使用multi开启事务
3）在A客户端设置age 为 20
4）在B客户端设置age为22
5）在A客户端执行事务exec
6）在A客户端查看age的值，发现A客户端执行的事务没有提交，因为watch的age的值已经被修改了，所以放弃事务


以上就是redis高级话题中的redis事务的实现部分，共勉！