redis 事务

最新推荐文章于 2024-09-14 17:41:44 发布

Aqua_yyds

最新推荐文章于 2024-09-14 17:41:44 发布

阅读量666

点赞数 23

分类专栏： redis 文章标签： redis 数据库 database 中间件

本文链接：https://blog.csdn.net/Aqua_yyds/article/details/137125945

版权

redis 专栏收录该内容

4 篇文章 0 订阅

订阅专栏

文章目录

redis 事务与 MySQL 事务的区别和联系

redis 的事务和 MySQL 的事务在概念上是类似的, 都是把一系列的操作绑定成一组, 能够让这一组操作批量执行.

首先来讲一下 MySQL 事务的四大特性:

原子性: 把多个操作打包成一个整体, 事务中的所有操作要么全都执行成功, 要么全都失败回滚, 不能只执行其中一部分操作.
一致性: 运行事务前后的数据结果都是合理有效的, 不会出现非法的中间状态.
隔离性: 事务并发执行过程中, 每个事务对其它事务操作都是透明的, 一个事务的中间结果对其它事务是不可见的. 隔离性可以避免并发执行之间产生的脏读, 幻读, 不可重复读等问题.
持久性: 事务中做出的修改都存在硬盘中.

然而, redis 的事务和 MySQL 的事务还是有一定区别的:

弱化的原子性: redis 并没有实现回滚的机制, 只能做到将事务中的所有操作批量执行, 并不能做到中间执行失败就回到初始状态.
不保证一致性: redis 并没有回滚机制, 所以事务中的数据可能会有执行失败的场景, 并不能保证结果的数据是合理有效的.
不涉及隔离性: redis 是单线程处理请求的, 并不会涉及到多线程环境下出现的问题.
不具备持久性: redis 是将数据存入内存中的, 虽然 redis 有持久化机制, 但是持久化机制是 redis-server 来完成的, 与事务无关.

所以, redis 事务存在的最主要的意义是为了将操作打包在一起执行, 避免其它客户端的命令插到中间. 为了实现这一点, redis 引入了一个队列(每一个客户端都会有一个), 开启事务的时候, 此时客户端输入的命令会发送给服务器并且进入这个队列, 当遇到了执行事务的命令的时候, 就会把这个队列中的任务都按照顺序依次执行.

redis 事务操作

MULTI: 开启一个事务, 成功返回 OK.

127.0.0.1:6379> multi
OK

EXEC: 执行事务

127.0.0.1:6379> multi
OK
127.0.0.1:6379> set key1 111
QUEUED
127.0.0.1:6379> set key2 222
QUEUED
127.0.0.1:6379> set key3 333
QUEUED
127.0.0.1:6379> exec
1) OK
2) OK
3) OK
127.0.0.1:6379>

每次添加一个操作的时候, 都会提示 “QUQUQD”, 说明这个操作已经进入到客户端的队列中了, 真正执行 exec 的时候, 客户端才会把上述的操作发送给服务器, 服务器根据这个队列中的操作依次执行.

DISCARD: 放弃当前的事务, 清空客户端的事务队列, 之前的操作不会被执行到.

127.0.0.1:6379> multi
OK
127.0.0.1:6379> set key1 111
QUEUED
127.0.0.1:6379> set key2 222
QUEUED
127.0.0.1:6379> discard
OK
127.0.0.1:6379> get key1
(nil)
127.0.0.1:6379> get key2
(nil)
127.0.0.1:6379>

WATCH: 在该客户端上监控一组具体的 key, 当开启了事务操作了一个 key, 但是还未执行事务的时候该 key 被其它客户端修改了, 此时再执行事务就会执行失败.

# 客户端 1
127.0.0.1:6379> watch key1
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set key1 111
QUEUED
127.0.0.1:6379> set key2 222
QUEUED

# 此时事务还未提交, 但是客户端 2 执行如下操作
127.0.0.1:6379> set key1 222
OK

# 此时客户端 1 再执行事务
127.0.0.1:6379> exec
(nil)
127.0.0.1:6379> get key1
"222"
127.0.0.1:6379> get key2
(nil)
127.0.0.1:6379>