Redis的事务提供了一种“将多个命令打包, 然后一次性、按顺序地执行”的机制。
redis事务的主要作用就是串联多个命令防止别的命令插队。
但是,事务并不具有传统数据库事务的特性,如回滚。
Redis中的事务可以通过以下命令来执行:
MULTI
:用于开启一个事务块,表示之后的命令将被放入事务队列中,但并不会立即执行。MULTI
和EXEC
之间的所有命令都将被添加到事务队列中。EXEC
:用于执行事务队列中的所有命令。执行事务后,事务队列会被清空。DISCARD
:用于取消事务,清空事务队列中的命令。WATCH
:监视一个或多个键,当被监视的键被修改时,事务将被打断。Redis事务分2个阶段:组队/打包阶段、执行阶段
示例:
redis 127.0.0.1:6379> MULTI
OK
redis 127.0.0.1:6379> SET book-name "Redis从入门到放弃"
QUEUED
redis 127.0.0.1:6379> GET book-name
QUEUED
redis 127.0.0.1:6379> SADD tag "Redis" "入门" "放弃"
QUEUED
redis 127.0.0.1:6379> SMEMBERS tag
QUEUED
redis 127.0.0.1:6379> EXEC
1) OK
2) "Redis从入门到放弃"
3) (integer) 3
4) 1) "Redis"
2) "入门"
3) "放弃"
事务错误处理方式分为两个阶段:组队时错误和执行时错误。
为了解决事务的冲突问题,可以使用锁,包括悲观锁和乐观锁。
悲观锁是一种对数据修改持有悲观态度的并发控制方式。它总是假设最坏的情况,每次读取数据时都默认其他线程会更改数据,因此需要加锁操作。
悲观锁的实现:
乐观锁相对于悲观锁而言,它假设数据一般情况下不会造成冲突,只在数据提交更新时才检测是否冲突。如果冲突,则返回异常信息,让用户决定如何处理。乐观锁适用于读多写少的场景,可以提高程序吞吐量。
乐观锁的实现:
Redis通过CAS (Check and Set) 实现乐观锁,使用WATCH
指令监听一个或多个键,当用户提交修改事务时,会检查监听的键是否发生变化。若没有发生变化,则提交成功;否则,事务失败。
例如,两个客户端在同一时间开始一个事务,他们都对同一个键的值进行了修改,但在执行事务的EXEC
命令时,只能有一个客户端的事务能够成功,另一个客户端的事务会因为键的值发生了改变而执行失败。
客户端1:
# 刷新数据库
127.0.0.1:6379> FLUSHDB
OK
# 设置key值
127.0.0.1:6379> set key 10
OK
# 监听key
127.0.0.1:6379> WATCH key
OK
# 开启事务
127.0.0.1:6379> MULTI
OK
客户端2:
# 监听key
127.0.0.1:6379> WATCH key
OK
# 开启事务
127.0.0.1:6379> MULTI
OK
客户端1:
# 指令加入队列
127.0.0.1:6379(TX)> INCR key
QUEUED
# 执行指令,可以看到执行成功,修改了一条数据,值被更新为11
127.0.0.1:6379(TX)> EXEC
1) (integer) 11
客户端2:
127.0.0.1:6379(TX)> INCR key
QUEUED
127.0.0.1:6379(TX)> exec
(nil)
Redis事务具有以下三个特性: