Redis (five) transaction

Redis (five) transaction

Multiple commands can be executed at once. It is a command group. In a transaction, all commands will be serialized (queued) and will not be cut in the queue;

One-time, sequential, exclusive execution of a series of commands in a queue

Three characteristics:

• Isolation: All commands will be executed in order, and the transaction will not be interrupted by commands sent by other clients during the execution process
• No isolation level: The commands in the queue will not be actually executed until they are submitted, and there is no such a headache as "a query in a transaction needs to see the update in the transaction, and a query outside the transaction cannot see it"
• Atomicity is not guaranteed: if one command fails, other commands may be executed successfully without rollback

Three steps:

• Open multi
• Enqueued
• Execute exec

Compared with relational database transactions:

• multi: can be understood as begin in relational transactions
• exec: can be understood as commit in relational transactions
• discard: can be understood as rollback in relational transactions

Be born together

Open the transaction, join the queue, execute together, and succeed

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> set k3 v3
QUEUED
127.0.0.1:6379> get k1
QUEUED
127.0.0.1:6379> set k4 v4
QUEUED
127.0.0.1:6379> exec					#一起执行事务
1) OK
2) OK
3) OK
4) "v1"
5) OK

Die together

Abandon the previous operation and restore to the original value

127.0.0.1:6379> multi					#开启事务
OK
127.0.0.1:6379> set k1 v111				#加入事务队列
QUEUED
127.0.0.1:6379> set k2 v222
QUEUED
127.0.0.1:6379> discard					#放弃事务，相当于回滚
OK
127.0.0.1:6379> get k1
"v1"

A mouse shit is bad for a pot of soup

Report an error, cancel all, restore to the original value

127.0.0.1:6379> multi									#开启事务
OK
127.0.0.1:6379> set k5 v5
QUEUED
127.0.0.1:6379> set lllll								#错误语句，报错
(error) ERR wrong number of arguments for 'set' command
127.0.0.1:6379> set k6 v6
QUEUED
127.0.0.1:6379> exec									#执行事务
(error) EXECABORT Transaction discarded because of previous errors.			#报错，队列命令全部取消
127.0.0.1:6379> keys *
1) "k2"
2) "k4"
3) "k3"
4) "k1"

Injustice and debt

Hold accountable, who’s wrong, who should we go to

Shown here does not support atomicity

127.0.0.1:6379> multi										#开启事务
OK
127.0.0.1:6379> incr k1
QUEUED
127.0.0.1:6379> set k5 v5
QUEUED
127.0.0.1:6379> set k6 v6
QUEUED
127.0.0.1:6379> exec
1) (error) ERR value is not an integer or out of range		#明确错误
2) OK
3) OK
127.0.0.1:6379> keys *
1) "k1"
2) "k2"
3) "k5"														#事务队列2执行成功
4) "k3" 													#事务队列3执行成功
5) "k4"
6) "k6"
127.0.0.1:6379> get k1                                      #事务队列1执行失败
"v1"

watch monitoring

Test: Simulate income and expenses

Under normal circumstances:

127.0.0.1:6379> set in 100							#收入   100
OK
127.0.0.1:6379> set out 0							#支出   0
OK
127.0.0.1:6379> multi								#事务开启
OK
127.0.0.1:6379> decrby in 20						#收入 - 20
QUEUED
127.0.0.1:6379> incrby out 20						#支出 + 20
QUEUED
127.0.0.1:6379> exec
1) (integer) 80
2) (integer) 20

in special cases:

127.0.0.1:6379> watch in				#监控收入in
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> decrby in 20
QUEUED
127.0.0.1:6379> incrby out 20
QUEUED
127.0.0.1:6379> exec
(nil)									#在执行exec之前，我开启了另一个窗口（线程），对监控的in做了修改，所以本次事务将被打断（失效），类似于“乐观锁”

unwatch: cancel the watch command's operation on all keys

• Once the exec command is executed, all the monitoring added before will automatically become invalid!