The transaction

  • Redis single commands are guaranteed atomicity, but transactions are not
  • Redis transactions have no concept of isolation levels
  • All commands in a transaction are not executed directly, only when the execution command is initiated

The essence of a Redis transaction: a set of commands All commands in a transaction are serialized. During the execution of a transaction, a sequence of commands is executed sequentially and exclusively

-- -- -- -- -- the queueset set set-- -- -- -- --Copy the code

Redis transactions:

  • Start transaction (multi)
  • Order in (……)
  • Execute transaction (exec)

Normally executed transaction

127.0.0.1:6379 > multi# start transaction
OK
Enter the queue127.0.0.1:6379 >setK1 v1 QUEUED 127.0.0.1:6379 >setK2 v2 QUEUED 127.0.0.1:6379> get k2 QUEUED 127.0.0.1:6379>set k3 v3
QUEUED
# execute transaction127.0.0.1:6379 >exec
1) OK
2) OK
3) "v2"4) OK 127.0.0.1:6379 >Copy the code

Give up the transaction

127.0.0.1:6379 > multi# start transactionOK 127.0.0.1:6379 >setK4 V4 QUEUED 127.0.0.1:6379> discard# cancel transactionOK 127.0.0.1:6379 > get k4None of the commands in the transaction queue will be executed
(nil)
Copy the code

Compiled exception

(code error command error) All commands in the transaction will not be executed

127.0.0.1:6379 > multi OK 127.0.0.1:6379 >setK1 v1 QUEUED 127.0.0.1:6379 >setK2 v2 QUEUED 127.0.0.1:6379 >setK3 v3 QUEUED 127.0.0.1:6379> getSet K3Wrong command
(error) ERR wrong number of arguments for 'getset' command127.0.0.1:6379 >setK4 v4 QUEUED 127.0.0.1:6379 >setK5 v5 QUEUED 127.0.0.1:6379 >exec            An error was reported during execution
(error) EXECABORT Transaction discarded because of previous errors.
127.0.0.1:6379> get k5          # All commands will not be executed(nil) 127.0.0.1:6379 >Copy the code

Runtime exception

If there is a syntax error in the transaction queue, other commands can be executed normally when the command is executed. The error command throws an exception

127.0.0.1:6379 >set k1 "v1"
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> incr k1         # will fail at executionQUEUED 127.0.0.1:6379 >setK2 v2 QUEUED 127.0.0.1:6379 >setK3 v3 QUEUED 127.0.0.1:6379> get K3 QUEUED 127.0.0.1:6379>exec            The first command failed, but was executed successfully
1) (error) ERR value is not an integer or out of range
2) OK
3) OK
4) "v3"127.0.0.1:6379 >Copy the code

Monitor the Watch

Pessimistic locking

  • Very pessimistic, think that there will be problems at any time, no matter what to do will be locked.

Optimistic locking

  • Very optimistic, think no problem at any time, so no lock. When updating the data, determine if anyone has changed the data in the meantime
  • Access to the version
  • Compare version when updating

Redis monitors tests

Normal Execution Succeeded

127.0.0.1:6379 >setMoney 100 OK 127.0.0.1:6379 >setOut 0 OK 127.0.0.1:6379> Watch money# Monitor money objectsOK 127.0.0.1:6379 > multiThe transaction completes normally, and no changes have occurred during the data period
OK
127.0.0.1:6379> decrby money 20
QUEUED
127.0.0.1:6379> incrby out 20
QUEUED
127.0.0.1:6379> exec(1)integer), 80 (2)integer6379 > 20 127.0.0.1) :Copy the code

Test multi-thread modification value, monitoring failure, use watch can be used as redis optimistic lock operation

Thread a

127.0.0.1:6379 > watch money# monitoring money
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> decrby money 10
QUEUED
127.0.0.1:6379> incrby out 10
QUEUED
127.0.0.1:6379> exec            If another thread changes our value before executing the transaction, the transaction will fail.(nil) 127.0.0.1:6379 >Copy the code

Thread 2

127.0.0.1:6379 > get the money"80"127.0.0.1:6379 >setMoney 1000 OK 127.0.0.1:6379 >Copy the code

The solution

127.0.0.1:6379 > unwatchIf the transaction fails, unlock itOK 127.0.0.1:6379 > watch moneyGet the new value, monitor again, select version
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> decrby money 1
QUEUED
127.0.0.1:6379> incrby money 1
QUEUED
127.0.0.1:6379> exec                If there is no change, the execution succeeds. If the execution fails, then continue to unlock - "obtain new value and monitor...... again(1)integer), 999 (2)integer6379 > 1000 127.0.0.1) :Copy the code
  • If the transaction fails, unlock it first
  • Get the new value, monitor again, select Version
  • If there is no change, the execution succeeds. If the execution fails, then continue to unlock – to obtain the new value and monitor…… again

Pay more attention to wechat public number full stack self-study community