redis事务和锁机制

目录

事务定义

 事务操作命令

 redis事务的错误处理

 redis事务冲突问题

        redis解决事务冲突的方法

Redis事务的三个特性

---

事务定义

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

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

        redis事务实现操作顺序的执行，是通过队列的实现的。

 事务操作命令

        事务操作的基本命令是：Multi，Exec，discard。

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

        组队过程中可以通过discard来放弃组队。

         案例：

 redis事务的错误处理

• 在组队过程中，某个命令出现了报错，在执行时，队列的所有命令都不会执行。

• 在组队过程中，都是正确的，但是，在执行时某个命令出现了错误，那只有错误命令不会被执行，其他正确的命令都会执行。

 redis事务冲突问题

        什么是冲突？以及为什么要解决冲突？

        模拟抢票的场景。当只有一张票时，此时，三个人看到同一张票，同时抢。在代码中表现为，三个线程同时从redis中获取票数，此时会有冲突，如果不解决冲突，三个线程取到票的数量都为1，都可以买到票，但是实际只有一张票。此时就会有问题。

        redis解决事务冲突的方法

• 悲观锁

        顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁。这样别人拿数据的时候就会阻塞直到拿到锁。传统的关系型数据库中就用到了很多这样的锁机制。比如：行锁，表锁等，读锁，写锁等，都是在操作前上锁。

        这种锁的缺点会导致效率变低。

比如上面买票的例子，三个人买一张票。第一个人买时，就会上锁，第二个和第三个人买不了，直到第一个人买完。

• 乐观锁

        顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁。但是在每次拿数据时会判断一下有没有人去更新这个数据，可以使用版本号等机制。

        乐观锁适用于多读的应用类型，这样可以提高吞吐量。redis就是利用这种check-and-set机制实现事务的。

比如上面买票的例子，三个人同时抢到这一张票，此时版本号为v1，但是第一个人实际抢到了这张票，在设置票数时，将数据库中票数量的版本号设为v1.1，第二个人修改票数量时，比较版本号，此时版本号不相同，不会进行操作，需要获得新数据才可以进行操作。

• 监视WATCH

        在执行multi之前，先执行watch key1 key2...；可以监视一个或者多个key，如果在事务执行前这些key被其他命令改动，那么事务会被打断。

•  取消监视unwatch

        取消watch命令对所有key的监视。

        如果在执行watch命令之后，exec命令或者discard命令先执行的话，就不需要再执行unwatch了。

Redis事务的三个特性

• 单独的隔离操作

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

• 没有隔离级别的概念

        事务队列中的命令没有提交之前都不会实际执行。

• 不保证原子性

        事务执行过程中如果有一条命令执行失败，其他命令仍然会被执行，不会回滚。