Redis 事务
Redis 事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序的执行。事务在执行的过程中，不会被其他客户端发送来的命令请求打断
Redis 事务的主要作用就是串联多个命令防止别的命令插队
Multi、Exec、Discard
从输入 Multi 命令开始，输入的命令都会依次进入命令队列中，但不会执行，知道输入 Exec 之后，Redis 会将之前命令队列中的命令依次执行，组队的过程中通过 Discard 来放弃组队。
- 组队成功，提交成功
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)> exec
1) OK
2) OK
127.0.0.1:6379>- 组队成功，放弃组队
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)> discard
OK
127.0.0.1:6379>- 组队失败，提交失败
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
(error) ERR wrong number of arguments for 'set' command
127.0.0.1:6379(TX)> exec
(error) EXECABORT Transaction discarded because of previous errors.
127.0.0.1:6379>- 组队成功，提交有成功有失败
127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)> set k1 v1
QUEUED
# 数字才能自增 1
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)> exec
1) OK
2) (error) ERR value is not an integer or out of range
3) OK
127.0.0.1:6379>事务的错误处理
组队中某个命令出现错误，执行时整个的队列都会被取消
执行阶段某个命令报出了错误，则只有报错的命令不会被执行，其他命令都会执行，不会回滚
事务冲突问题
悲观锁（Pessimistic Lock）：每次拿数据都认为会被别人修改，每次获取都会上锁，别人拿数据就会 block 直到它拿到锁。传统的关系型数据库里面就用到了很多这种锁机制，比如行锁、表锁、读锁、写锁等，都是在操作之前先上锁
乐观锁（Optimistic Lock）：每次拿数据都认为不会被别人修改，所以不会上锁，但是更新的时候会判断一下在此期间别人有没有更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量。Redis 就是利用这种 check-and-set 机制实现事务的。
watch key [key ...]
在执行 multi 之前，先执行 watch key1 [key2]，可以监视一个（或多个）key，如果事务执行之前这个（或这些）key 被其他命令改动，那么事务将被打断。
# 终端 1
127.0.0.1:6379> set balance 100
OK
127.0.0.1:6379> watch balance
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)> incrby balance 100
QUEUED
127.0.0.1:6379(TX)> exec
1) (integer) 200
127.0.0.1:6379># 终端 2，在终端 1 执行 exec 之前进行监视
127.0.0.1:6379> watch balance
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)> incrby balance 200
QUEUED
127.0.0.1:6379(TX)> exec
(nil)
127.0.0.1:6379>unwatch
取消 watch 命令对所有 key 的监视
如果在执行 watch 命令之后，exec 命令或 discard 命令先被执行了的话，那么就不需要再执行 unwatch 了
Redis 事务三特性
单独的隔离操作
- 事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求打断
没有隔离级别的概念
- 队列中的命令没有提交之前都不会实际执行，因为事务提交前任何指令都不会被实际执行
不保证原子性
- 事务中如果有一条命令执行失败，其后的命令仍然会被执行，不会回滚
事务秒杀案例
案例存在问题
库存超卖（用 redis 乐观锁解决：watch；分布式锁：tryLock）
使用乐观锁后造成库存遗留问题（碰巧都失败了，导致库存有剩余）。 LUA 脚本解决
每次连接 redis 都是去 new 的，会有连接超时情况（连接池）
public static void main(String[] args) {
new Thread(() -> {
for (int i = 0; i < 20; i++) {
String res = secKill(Long.valueOf(new Random().nextInt(50)), "1001");
System.out.println(Thread.currentThread().getName() + " -> " + res);
}
}, "A").start();
new Thread(() -> {
for (int i = 0; i < 20; i++) {
String res = secKill(Long.valueOf(new Random().nextInt(50)), "1001");
System.out.println(Thread.currentThread().getName() + " -> " + res);
}
}, "B").start();
new Thread(() -> {
for (int i = 0; i < 20; i++) {
String res = secKill(Long.valueOf(new Random().nextInt(50)), "1001");
System.out.println(Thread.currentThread().getName() + " -> " + res);
}
}, "C").start();
}public static String secKill(Long id, String skuCode) {
// 用户 id 和 skuCode 判断非空
if (id == null || skuCode == null) {
return "用户 id 或 skuCode 为空";
}
// 连接 redis
Jedis jedis = new Jedis("39.105.172.126", 6379);
jedis.auth("520598");
// 3、拼接 key
// 3-1、库存 key
String stockKey = "sk:" + skuCode + ":qt";
// 3-2、秒杀成功用户 key
String userKey = "sk:" + skuCode + ":user";
// 监视库存
jedis.watch(stockKey);
// 4、获取库存，如果库存为 null，秒杀还没有开始
String skuNum = jedis.get(stockKey);
if (skuNum == null) {
return "秒杀还未开始，请稍后再试";
}
// 5、判断用户是否重复秒杀操作
if (jedis.sismember(userKey, id.toString())) {
return "您已经参与过秒杀了，请勿重复参与";
}
// 6、判断商品数量，如果库存数量小于 1，秒杀结束
int skuNumber = Integer.parseInt(skuNum);
if (skuNumber < 1) {
jedis.close();
return "秒杀已经结束";
}
// 7、秒杀过程（使用事务）
Transaction multi = jedis.multi();
// 7-1、库存 -1
multi.decr(stockKey);
// 7-2、用户数据添加
multi.sadd(userKey, id.toString());
// 执行
List<Object> results = multi.exec();
if (results == null || results.size() == 0) {
jedis.close();
return "秒杀失败";
}
jedis.close();
return "秒杀成功!";
}