If redis needs to execute a set of commands, in order to maintain the consistency and continuity of data, it needs to use transaction. In this paper, some simple examples are given to briefly describe the content related to redis transaction, which is only for learning and sharing. If there are any shortcomings, please correct them.
Redis transaction involves command
- Discard: to cancel a transaction. Discard is paired with multi and cannot be used alone.
- Multi: marks the beginning of a transaction block.
- Exec: execute commands in all transactions in sequence.
- Watch: monitors one or more keys.
- Unwatch: cancel monitoring.
Transaction basic operation
The basic transaction starts with multi and ends with exec. In the middle is a set of redis commands, as follows:
1 127.0.0.1:6379> MULTI 2 OK 3 127.0.0.1:6379> SET NAME HSIANG 4 QUEUED 5 127.0.0.1:6379> SET AGE 20 6 QUEUED 7 127.0.0.1:6379> SET SEX MALE 8 QUEUED 9 127.0.0.1:6379> SET ADDR SHENZHEN 10 QUEUED 11 127.0.0.1:6379> EXEC 12 1) OK 13 2) OK 14 3) OK 15 4) OK 16 127.0.0.1:6379>
If the transaction is cancelled, the data will be restored to the state before the transaction is executed, starting with multi and ending with discard, as follows:
1 127.0.0.1:6379> GET AGE 2 "20" 3 127.0.0.1:6379> MULTI 4 OK 5 127.0.0.1:6379> INCR AGE 6 QUEUED 7 127.0.0.1:6379> INCR AGE 8 QUEUED 9 127.0.0.1:6379> INCR AGE 10 QUEUED 11 127.0.0.1:6379> DISCARD 12 OK 13 127.0.0.1:6379> GET AGE 14 "20"
Transaction partial execution
In redis transaction, if there is no syntax error in a group of commands to be executed, but there is a data type error, when exec is executed, other commands are executed successfully, and the execution of error data fails, which means partial success. As follows:
1 127.0.0.1:6379> MULTI 2 OK 3 127.0.0.1:6379> INCR AGE 4 QUEUED 5 127.0.0.1:6379> INCR ADDR 6 QUEUED 7 127.0.0.1:6379> INCR AGE 8 QUEUED 9 127.0.0.1:6379> EXEC 10 1) (integer) 21 11 2) (error) ERR value is not an integer or out of range 12 3) (integer) 22 13 127.0.0.1:6379> GET AGE 14 "22"
If the redis command to be executed has syntax errors, it will be rolled back during exec, as shown below:
1 127.0.0.1:6379> MULTI 2 OK 3 127.0.0.1:6379> INCR AGE 4 QUEUED 5 127.0.0.1:6379> SET ADDR 6 (error) ERR wrong number of arguments for 'set' command 7 127.0.0.1:6379> INCR AGE 8 QUEUED 9 127.0.0.1:6379> EXEC 10 (error) EXECABORT Transaction discarded because of previous errors. 11 127.0.0.1:6379> GET AGE 12 "22"
The lock is divided into optimistic lock and pessimistic lock
- Pessimistic lock: just like its name, it has strong exclusive and exclusive characteristics. It refers to a conservative attitude towards data being modified by the outside world (including other current transactions of the system, as well as transactions from the external system).
- Optimistic locking: it is relative to pessimistic locking. Optimistic locking assumes that the data will not cause conflict in general, so when the data is submitted for update, it will formally detect whether the data is in conflict or not. If a conflict is found, it will return the wrong information to the user and let the user decide how to do it. Optimistic lock is suitable for the scenario of many read operations, which can improve the throughput of the program.
When the value of the monitored key changes before the transaction, the transaction is not executed. The transaction will not be executed until the monitoring is cancelled, as shown below:
1 127.0.0.1:6379> WATCH balance 2 OK 3 127.0.0.1:6379> set balance 300 4 OK 5 127.0.0.1:6379> MULTI 6 OK 7 127.0.0.1:6379> INCRBY balance 10 8 QUEUED 9 127.0.0.1:6379> DECRBY debt 10 10 QUEUED 11 127.0.0.1:6379> EXEC 12 (nil) 13 127.0.0.1:6379> GET balance 14 "300" 15 127.0.0.1:6379> UNWATCH 16 OK
Characteristics of redis transaction
- Isolated operation: all commands in the transaction are serialized and executed in sequence. During the execution of the transaction, it will not be interrupted by other command requests.
- There is no concept of isolation level: the commands in the queue are not actually executed before they are submitted, so there is no update in the transaction.
- Atomicity is not guaranteed: in the same transaction of redis, if one command fails to execute, other commands will be executed and will not be rolled back (different from relational database).
Early development of Baidi City
Author: Li Bai (Tang Dynasty)
In the clouds of the White Emperor’s departure, the river mausoleum is still thousands of miles away.
The boat passed thousands of mountains with apes shouting without endless.