redis-06-事务

    xiaoxiao2021-03-25  96

    Redis事务简介和事务相关的命令 1 multi2 exec3 discard4 watchunwatch 事务操作示例 1 正常结束的事务2 正常取消的事务3 一个老鼠害一锅汤4 对的执行错的回滚5 watchunwatch示例6 总结 Redis事务的总结参考资料

    1 Redis事务简介

    Redis可以一次执行多个命令,本质是一组命令的集合。一个事务中的所有命令都会序列化,按顺序地串行化执行而不会被其它命令插入。

    也就是说一次性、顺序性、排他性的执行一组命令,和传统的RDBMS的事务有点类似。

    事务是一个单独的隔离操作:事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中,不会被其他客户端发送来的命令请求所打断。事务是一个原子操作:事务中的命令要么全部被执行,要么全部都不执行。

    2 和事务相关的命令

    2.1 multi

    该命令开启一个事务,它总是返回 OK.

    相当于session.begainTransaction().

    2.2 exec

    执行一个事务块内的所有命令。

    相当于session.commit().

    同时exec之前的监控所都被取消了。

    2.3 discard

    取消事务。

    相当于session.rollback().

    2.4 watch/unwatch

    被 WATCH的键会被监视。如果有至少一个被监视的键在 EXEC 执行之前被修改了, 那么整个事务都会被取消, EXEC 返回nil-reply来表示事务已经失败。

    相对的,UNWATCH命令用来取消对所有key的监视.

    3 事务操作示例

    3.1 正常结束的事务

    127.0.0.1:6379> FLUSHALL OK 127.0.0.1:6379> MULTI # 开启事务 OK # 该命令总是返回OK 127.0.0.1:6379> set k1 v1 QUEUED # 入队,等待exec 127.0.0.1:6379> get k1 QUEUED # get操作同样是入队 127.0.0.1:6379> set k2 v2 QUEUED # 入队 127.0.0.1:6379> EXEC 1) OK # set k1 v1 的返回值 2) "v1" # get k1 的返回值 3) OK # set k2 v2 的返回值 127.0.0.1:6379> keys * 1) "k1" 2) "k2" 127.0.0.1:6379>

    3.2 正常取消的事务

    127.0.0.1:6379> FLUSHALL OK 127.0.0.1:6379> set k1 v1 # 先准备个历史数据 OK 127.0.0.1:6379> get k1 "v1" 127.0.0.1:6379> MULTI # 开启事务 OK 127.0.0.1:6379> set k1 v11111 # 修改k1的值为v11111 QUEUED 127.0.0.1:6379> get k1 QUEUED 127.0.0.1:6379> set k2 v222 QUEUED 127.0.0.1:6379> DISCARD # 取消事务 OK 127.0.0.1:6379> keys * 1) "k1" # set k2 v2 被回滚了 127.0.0.1:6379> get k1 "v1" # set k1 v11111 被回滚了 127.0.0.1:6379>

    3.3 一个老鼠害一锅汤

    127.0.0.1:6379> FLUSHALL OK 127.0.0.1:6379> MULTI # 开启事务 OK 127.0.0.1:6379> set k1 v1 QUEUED 127.0.0.1:6379> set k2 v2 QUEUED 127.0.0.1:6379> a-error-cmd # 故意乱写一通 (error) ERR unknown command 'a-error-cmd' 127.0.0.1:6379> set k4 v4 QUEUED 127.0.0.1:6379> exec # 提交事务 # 上面手动制造的a-error-cmd导致的 (error) EXECABORT Transaction discarded because of previous errors. 127.0.0.1:6379> keys * (empty list or set) # 一条也没有生效 127.0.0.1:6379>

    3.4 对的执行错的回滚

    127.0.0.1:6379> FLUSHALL OK 127.0.0.1:6379> MULTI OK 127.0.0.1:6379> set k1 v1 QUEUED 127.0.0.1:6379> get k1 QUEUED 127.0.0.1:6379> INCRBY k1 10 QUEUED 127.0.0.1:6379> get k1 QUEUED 127.0.0.1:6379> exec 1) OK 2) "v1" 3) (error) ERR value is not an integer or out of range 4) "v1" 127.0.0.1:6379>

    和上一个示例中的错误不同的是:

    此处的incrby相当于Java中的运行时异常,只有在真正运行时才能发现的错误(只回滚错误的命令)而上一个示例中伪造的命令a-error-cmd相当于Java中在静态编译时就可以确定的错误(全部回滚)

    3.5 watch/unwatch示例

    此处的个人信用卡的示例来自尚硅谷教学视频:

    正常的watch示例—两笔金额的变动在同一个事务内发生 127.0.0.1:6379> set balance 100 OK 127.0.0.1:6379> set debt 0 OK 127.0.0.1:6379> WATCH balance OK 127.0.0.1:6379> MULTI OK 127.0.0.1:6379> DECR balance QUEUED 127.0.0.1:6379> INCR debt QUEUED 127.0.0.1:6379> exec # 监控锁也被取消了 1) (integer) 99 2) (integer) 1 127.0.0.1:6379> 被中断了的watch

    3.6 总结

    Watch指令,类似乐观锁,事务提交时,如果Key的值已被别的客户端改变(比如某个list已被别的客户端push/pop过了)整个事务队列都不会被执行.

    通过WATCH命令在事务执行之前监控了多个Keys,倘若在WATCH之后有任何Key的值发生了变化,

    EXEC命令执行的事务都将被放弃,同时返回Nullmulti-bulk应答以通知调用者事务执行失败.

    4 Redis事务的总结

    事务相关的命令

    multi开启事务开启事务后,提交的命令不会被立即执行,而是入队exec提交事务,执行命令discard回滚放弃事务

    事务的特性

    事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中,不会被其他客户端发送来的命令请求所打断队列中的命令没有提交之前都不会实际的被执行redis同一个事务中如果有一条命令执行失败,正确的命令仍然会被执行,不会回滚(不保证原子性)

    参考资料

    尚硅谷思维导图https://redis.io/documentationhttp://www.redis.cn/documentation.html
    转载请注明原文地址: https://ju.6miu.com/read-22543.html

    最新回复(0)