文章目录
前言
Redis事务本质：一组命令的集合！一个事务中的所有命令都会被序列化，在事务执行过程中，会按照顺序执行！一次性、顺序性、排他性!执行一些列的命令。
-------队列 set set set 执行-------
一、概述
Redis事务本质：一组命令的集合！
Redis事务没有隔离性概念！
所有的命令在事务中，并没有直接被执行!只有发起执行命令的时候才会执行!Exec
Redis单条命令式保存原子性的，但是事务不保证原子性!
redis事务的三个阶段：
- 开启事务（multi）
- 命令入队（…）
- 执行事务（exec）
二、Redis事务使用
1.正常执行事务
127.0.0.1:6379> multi # 开启事务OK ## 命令入队127.0.0.1:6379(TX)> set k1 v1 QUEUED 127.0.0.1:6379(TX)> set k2 v2 QUEUED 127.0.0.1:6379(TX)> get k2 QUEUED 127.0.0.1:6379(TX)> set k3 v3 QUEUED 127.0.0.1:6379(TX)> exec # 执行事务OK OK "v2"OK
2.取消事务
127.0.0.1:6379> multi #开启事务OK 127.0.0.1:6379(TX)> set k1 v1 QUEUED 127.0.0.1:6379(TX)> set k2 v2 QUEUED 127.0.0.1:6379(TX)> set k4 v4 QUEUED 127.0.0.1:6379(TX)> discard #取消事务OK 127.0.0.1:6379> get k4 #事务中的命令都不会被执行(nil)
3.编译型异常
即代码有问题！命令有错！事务中所有的命令都不会被执行！
127.0.0.1:6379> multi OK 127.0.0.1:6379(TX)> set k1 v1 QUEUED 127.0.0.1:6379(TX)> set k2 v2 QUEUED 127.0.0.1:6379(TX)> set k3 v3 QUEUED 127.0.0.1:6379(TX)> getset k3 #错误的命令(error) ERR wrong number of arguments for'getset' command 127.0.0.1:6379(TX)> set k4 v4 QUEUED 127.0.0.1:6379(TX)> set k5 v5 QUEUED 127.0.0.1:6379(TX)> exec #执行事务报错！(error) EXECABORT Transaction discarded because of previous errors. 127.0.0.1:6379> get k5 #所有的命令都不会被执行！(nil)
4.运行时异常（1/0）
如果事务队列中存在语法型错误，那么执行命令的时候，其他命令是可以正常执行的，错误命令抛出异常。
127.0.0.1:6379> set k1 "v1"OK 127.0.0.1:6379> multi OK 127.0.0.1:6379(TX)> incr k1 #会执行的时候失败QUEUED 127.0.0.1:6379(TX)> set k2 v2 QUEUED 127.0.0.1:6379(TX)> set k3 v3 QUEUED 127.0.0.1:6379(TX)> get k3 QUEUED 127.0.0.1:6379(TX)> exec 1) (error) ERR value is not an integer or out of range #虽然第一条命令报错了，但是依旧正常执行成功了！2) OK 3) OK 4) "v3"127.0.0.1:6379> get k2 "v2"127.0.0.1:6379> get k3 "v3"
5.清空数据库
flushdb命令只会清除当前数据库中的数据，而不会影响其他数据库
flushall会清除Redis实例所有数据库（0-15）的缓存数据，执行时候需要小心
flushdb flushall
6.监控
watch（乐观锁实现）
- 悲观锁
悲观锁（Pessimistic Lock），顾名思义，就是很悲观。
认为什么时候都会出问题，无论做什么都会加锁！
每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁。
这样别人想拿到这个数据就会 block 直到它拿到锁。
传统的关系型数据库里面就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在操作之前先上锁。- 乐观锁
乐观锁（Optimistic Lock），顾名思义，就是很乐观。
认为什么时候都不会出问题，所以不会上锁！
但是在更新的时候会判断一下再此期间别人有没有去更新这个数据，可以使用版本号等机制。（即获取version，更新的时候比较version）
乐观锁适用于多读的应用类型，这样可以提高吞吐量。
乐观锁策略：提交版本必须大于记录当前版本才能执行更新。
1.乐观锁正常执行成功
127.0.0.1:6379> set money 100OK 127.0.0.1:6379> set out 0OK 127.0.0.1:6379> watch money #监视money对象OK 127.0.0.1:6379> multi #事务正常结束，数据期间没有发生变动，这个时候就正常执行成功OK 127.0.0.1:6379(TX)> decrby money 20QUEUED 127.0.0.1:6379(TX)> incrby out 20QUEUED 127.0.0.1:6379(TX)> exec 1) (integer) 802) (integer) 20
2.多线程
使用watch可以当做redis的乐观锁操作
线程1
127.0.0.1:6379> watch money #监视 moneyOK 127.0.0.1:6379> multi OK 127.0.0.1:6379(TX)> decrby money 10QUEUED 127.0.0.1:6379(TX)> incrby out 10QUEUED
线程2
127.0.0.1:6379> get money "80"127.0.0.1:6379> set money 1000OK
此时在线程1中输入exec会发现事务提交失败
127.0.0.1:6379(TX)> exec #执行之前，另外一个线程，修改了我们的值，这个时候，就会导致事务执行失败(nil)
如果修改失败，获取最新的值就好。
总结
以上就是Redis事务的相关操作，Redis的乐观锁可以实现秒杀系统。
