Redis的事务机制

Posted 2020-09-18

1、redis的事务是什么

    可以一次执行多个命令，本质是一组命令的集合，一个事务中的所有命令都会被序列化，按顺序地串行化执行而不会被其它命令插入，不许加塞（排队时后来者插到先到者前面的行为。）

    也就是说，在队列中，一次性、顺序性、排他性的执行一系列命令的行为。

    

    看看官方的介绍：

    注： redis 的事务是能够使用 MULTI 命令的行为，这个命令通常会响应为 OK，在这种情况下，使用者可以进行多个命令的操作，redis会安排它们入队列而不是执行这些命令，这些所有命令在键入 EXEC 时才会被调用。

    如果调用 DISCARD 命令将会刷新事务队列，而后退出事务。

2、具体的实际操作

    a、 MULTI: 标记一个事务块的开始

    EXEC:  执行所有事务块内的命令

    DISCARD: 取消事务，放弃执行事务块内的所有命令

    

    注：图示为正常执行的情况

    注：图示为放弃事务执行的情况

    注: 图示中，键入 getset v2 时发生了错误，所以在最后执行时所有命令都没有执行。（类似于Java 的编译期错误。）

    注：k1 为字符串，不可以进行数字操作，但是在执行了  EXEC 后才发现，后续的操作一样执行。（类似于 java 的运行期错误。）

    b、WATCH: 监视一个（或者多个）key,如果在事务之前这个（或者这些）key被其他的命令所改动，那么事务将会被打断

    UNWATCH: 取消 WATCH 命令对所有 key 的监视。

  

     注： 先设置 balance、debt 两个变量，然后再执行watch balance 和 multi 命令，在执行multi

命令之后，使用另一个终端开启另外一个客户端并改动 balance 的值后发现，exec 指令命令并不成功。（即redis事务不允许加塞。）

    注： 可以看到，unwatch 可以取消对所有 key 的监控，再 watch 一下，获取最新的 key 的状态。

3、redis事务机制的三特性：

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

    b、没有隔离级别的概念：队列中的命令没有提交之前都不会实际的被执行，因为事务提交之前任何指令都不会被实际执行，也就不存在“事务内的查询要看到事务里的更新，事务外的查询不能够看到”的问题。

    c、不保证原子性: redis同一个事务中如果有一条命令执行失败，其后的命令仍然会被执行。没有回滚操作。

    附：乐观锁和悲观锁的理解

    

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

    乐观锁： （Optimistic  Lock），顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制，乐观锁适用于多读的应用类型，这样可以提高吞吐量。（提交版本必须大于记录当前版本才能够执行更新。）

本文出自 “12392717” 博客，请务必保留此出处http://12402717.blog.51cto.com/12392717/1925108