Redis中的事务和事务冲突

Redis事务是一个单独的隔离操作：事务中的所有命令都会被序列化、按顺序的执行，事务在执行的过程中，不会被其他客户端发来的命令请求所打断。

Redis事务的主要作用是串联多个命令防止别的命令插队。

Redis 事务可以一次执行多个命令， 并且带有以下三个重要的保证：

• 批量操作在发送 EXEC 命令前被放入队列缓存。
• 收到 EXEC 命令后进入事务执行，事务中任意命令执行失败，其余的命令依然被执行。
• 在事务执行过程，其他客户端提交的命令请求不会插入到事务执行命令序列中。

一个事务从开始到执行会经历以下三个阶段：

• 开始事务。
• 命令入队。
• 执行事务。

Multi、Exec、discard

从输入Multi命令开始，输入的命令都会依次进入命令队列中，但不会执行，直到输入Exce后，Redis会将之前的命令队列中的命令依次执行。

discard：中断组队过程

 

以上为成功的情况，下面列举事务错误处理：

1.在组队时有命令错误，最终该事务中的所有命令均不执行

 

 2.若组队阶段没有发生错误，在执行阶段发生错误，失败的命令无法执行，其他的命令可以成功执行

 事务冲突

例：

当前有10000元，一个请求消费8000，一个请求消费5000，一个请求消费1000

 导致结果为-4000.

对于以上事务冲突问题，我们通过加锁的方式解决

悲观锁

即很悲观，每次去拿数据时都认为别人会修改，所以在每次获取数据时都上锁，使别人无法获取数据直至你使用完写回为止。

传统的关系型数据库里面用到了很多这种锁机制，比如行锁、表锁、读锁、写锁，都是在进行操作之前先上锁

缺点：效率较低，只能一个人一个人的使用

 乐观锁

即比较乐观，每次拿数据时都认为别人不会修改，所以不进行上锁，但是在更新时会判断一下在此期间有没有人去更新这个数据（采用版本号机制）。

乐观锁适用于读操作较多的应用类型，提高吞吐量。例如：抢票

利用check-and-set机制实现事务

WATCH key[key...]（乐观锁的使用）

在执行multi之前，先执行watch key1 [key2]来监视一个或多个key，如果在事务执行之前这个(或这些) key 被其他命令所改动，那么事务将被打断。

例:在第一个窗口中对balance进行修改自动打断第二个窗口中的事务

 

 unwatch：取消对所有key监控

 Redis事务的三特性

单独的隔离操作

事务中的所有命令都会被序列化、按顺序的执行，事务在执行的过程中，不会被其他客户端发来的命令请求所打断。

没有隔离级别的概念

 队列中的命令在没有提交前不会实际执行

不保证原子性

食物中如果有一条命令执行失败，其后的命令依然被执行，没有回滚