table of Contents
1. Introduction to Redis transaction
Three, optimistic lock and pessimistic lock
Xiaobai learns the second record of Redis. The last one is mainly to get to know Redis and understand its data types and underlying data structure. For details, see " Introduction to Redis, starting from the underlying data structure and application principles ." Then I want to record the part of Redis transaction in this article. I feel that it is also a more important content. The ACID feature of transaction is not unique to Redis. Mysql database also has it. So I think this general feature is the core point of the database, and I need to understand the principle.
The database is a multi-user-oriented shared management system with concurrency control and blockade mechanisms to ensure the integrity and normal operation of the database. A transaction is a unit that guarantees integrity, concurrency control, and a lockout mechanism . It consists of a series of database commands as a collective unit. There are transactions in both relational and non-relational databases. Let's take a look at the relevant content of Redis transactions.
1. Introduction to Redis transaction
The basic commands implemented by Redis transactions: MULTI, EXEC, DISCARD, WATCH .
- MULTI: Start the Redis transaction and set the client to the transaction state.
- EXEC: Submit the transaction, execute the MULTI command to the command queue between EXEC, and the client is in a non-transactional state at this time.
- DISCARD: Cancel the transaction, clear all commands in the transaction queue, and the client exits the transaction state.
- WATCH: Monitor key-value pairs. When all monitored key-value pairs have not been modified, the transaction is executed normally, otherwise the transaction will not be executed.
Redis transactions currently guarantee that the commands in a transaction requested by a client can be executed continuously, and no command requests sent by other clients will be sent during this process. When receiving the MULTI command, a transaction context is opened, and subsequent commands will be placed in a queue . These commands will be executed after the server receives the EXEC command.
Two, ACID characteristics
1. Atomicity
The atomicity of the transaction means that after the transaction state is started, the commands in the queue are regarded as a whole, and Redis either executes all of the command queues successfully or fails to execute all of them.
127.0.0.1:6379> set name "xiaochen"
OK
127.0.0.1:6379> set age 20
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set name "charzous"
QUEUED
127.0.0.1:6379> set age 21
QUEUED
127.0.0.1:6379> incrby age 3
QUEUED
127.0.0.1:6379> exec
1) OK
2) OK
3) (integer) 24
127.0.0.1:6379> get name
"charzous"
127.0.0.1:6379> get age
"24"
127.0.0.1:6379>It can be seen that if the transaction status is not turned on, the input command will return with " OK " after the execution is complete ; after turning on multi , the input command will return with " QUEUE ", indicating that the command has entered the queue. Finally, after the exec command executes the commands in the queue, it returns all the execution results in an array.
Next, verify the atomicity of the transaction, and deliberately enter the wrong command format : set (without key-value)
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set name "test"
QUEUED
127.0.0.1:6379> set age 18
QUEUED
127.0.0.1:6379> set
(error) ERR wrong number of arguments for 'set' command
127.0.0.1:6379> set sex "male"
QUEUED
127.0.0.1:6379> exec
(error) EXECABORT Transaction discarded because of previous errors.
127.0.0.1:6379>(error) EXECABORT Transaction discarded because of previous errors.
Error information is returned. Redis found that there was an incorrect command input in the execution queue process, so the execution of the transaction failed, and the information just checked did not update or increase.
127.0.0.1:6379> get age
"24"
127.0.0.1:6379> get name
"charzous"
127.0.0.1:6379> get sex
(nil)
127.0.0.1:6379>There is another situation here, the type of command entered is wrong, for example , if you add 5 to the name field at this time: incrby name 5, the following situation will occur:
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set name "test"
QUEUED
127.0.0.1:6379> set age 18
QUEUED
127.0.0.1:6379> incrby name 5
QUEUED
127.0.0.1:6379> set sex "male"
QUEUED
127.0.0.1:6379> exec
1) OK
2) OK
3) (error) ERR value is not an integer or out of range
4) OK
127.0.0.1:6379>At this time, only the command with the wrong type will fail to execute, and other commands will not be affected.
127.0.0.1:6379> get name
"test"
127.0.0.1:6379> get age
"18"
127.0.0.1:6379> get sex
"male"2. Consistency
The consistency of the transaction means that the data in the database is consistent before and after the transaction is executed. At first, I don't think it is easy to understand. The consistency here is that the database changes from the current state to a new state, and the data still meets the definition and requirements of the data itself before and after, and does not contain illegal or invalid dirty data . The literal meaning should be: the definition of the data itself is the characteristics of the type of the data and the constraints on the data type remain unchanged.
Just as the atomicity of the transaction is verified above, if the wrong command is entered, the transaction execution fails, which guarantees the atomicity and consistency.
3. Isolation
Transaction isolation means that multiple users access the database concurrently, and the database will open a transaction for each user separately. They do not interfere with each other and are isolated from each other, which achieves the effect of executing transactions in a concurrent state and serial execution. Exactly the same.
Because Redis has its own characteristics, it uses a single-process, single-threaded model to achieve key-value pair storage. When executing database commands, it uses a single-threaded method. Other commands will not be executed until the last transaction is executed.
4, endurance
Transaction durability means that after a transaction is executed correctly, the changes to the database are permanent. Even if the database encounters a failure, the operation will not disappear after the transaction is executed.
The persistence of Redis comes from its unique persistence method. In Redis, including AOF and RDB persistence methods, asynchronous execution.
The two persistence methods have their own advantages and disadvantages, and they can be combined with advantages and scenarios.
Three, optimistic lock and pessimistic lock
In this part, optimistic locking and pessimistic locking are exactly the read and write data mechanism used in Redis transactions, and the WATCH command uses this principle.
- Optimistic lock
As the name suggests, this kind of lock has an optimistic personality. Every time I go to the database to read data, I think that others will not modify the data and will not lock the data. But it is also rough and detailed. When updating the data, it will judge whether the data has been modified by others during the period. If it has been modified, the update is abandoned; otherwise, the update operation is performed. Use scenario: read more and write less, improve throughput.
Implementation strategy: version number mechanism.
There is a "version" field in the data table, which records the version number of the data. It will be read when reading data, and the version number is +1 when writing data. Compare the version number in your hand with the one in the data table. If it is higher than the version number in the table, update the data; otherwise, it means the data is out of date and does not update.
- Pessimistic lock
Similarly, as the name suggests, this lock has a pessimistic personality. Every time you fetch data, you will think that it has been modified by others, so you will lock it every time to restrict the use of others. In traditional relational databases, there are a large number of pessimistic locks: row locks, table locks, read locks, and write locks. It can be seen that the efficiency is obviously limited.
Four, WATCH command
The WATCH command in the transaction is an optimistic lock . Used to monitor the commands in the transaction, so that the EXEC command needs to be executed conditionally.
Only under the premise that all the keys monitored by the WATCH command have not been modified, the transaction can be executed successfully. Otherwise, the server refuses to execute and returns an empty reply that the execution failed to the client.
Implementation strategy:
When the monitored key executes database related commands, it will call the touchWatchKey function to open the client REDIS_DIRTY_CAS logo that monitors the modified database key . When the server receives the EXEC command, it will determine whether the client opens this logo to decide whether to execute the transaction .
Verify the effect of the WATCH command.
If you think it’s good, welcome to "one-click, three-link", like, bookmark, follow, comment directly if you have any questions, and exchange and learn!
My CSDN blog: https://blog.csdn.net/Charzous/article/details/114546348