definition
A Redis transaction is a single isolated operation (unlike MySQL): all commands in the transaction are serialized and executed in order. During the execution of the transaction, it will not be interrupted by command requests sent by other clients.
The main function of Redis transactions isto connect multiple commands in series to prevent other commands from jumping in the queue.
Multi、Exec、discard
Start from entering the Multi command, and the commands entered will be in sequence Enter the command queue, but will not execute, until Exec is entered, Redis will execute the commands in the previous command queue in sequence.
You can abandon the team formation bydiscard during the team formation process.
Example
1.The team formation was successful and the submission was successful.
2.An error occurred during the team formation stage and the submission failed. (We can see from the picture that if an error occurs in the team, all queues will be canceled when is executed. )
3.The team formation is successful, and the submission may be successful or failed. (If a command reports an error during the execution phase, only the command that reported the error will not be executed, and other commands will be executed and no response will be returned. Roll)
Why do we need to complete the transaction?
Multiple read and write operations are combined into a logical unit for execution, either all succeed or all fail. Applications will no longer care about half-success and half-failure situations when dealing with these problems, nor will they be bound to various unreliable underlying systems.
Resolve transaction conflicts--Redis pessimistic lock
Scenes:
You have 10,000 yuan, and it’s Double 11 now. Your ex-girlfriend, current girlfriend, and you all know your bank account number and password, and they all want to buy things on Double 11.
A request is made to reduce the amount by 8000
A request to reduce the amount by 5000
A request to reduce the amount by 1000
Pessimistic Lock(Pessimistic Lock), as the name suggests, it is very pessimistic. Every time you go to get the data, you think that others will modify it, so Every time it gets data, it will be locked, so that if others want to get the data, it will block (block means that others cannot operate, blocking state) until it gets the lock. Many such lock mechanisms are used in traditional relational databases, such as row lock< a i=6>, table lock, etc., read lock, a>write lock, etc., are all locked before doing the operation.
Resolve transaction conflicts--Redis optimistic lock
Optimistic Lock(Optimistic Lock), As the name suggests, it is very optimistic and gets data every time When updating, it is believed that others will not modify it, so it will not be locked. However, when updating, it will be judged whether others have updated the data during this period. You can use mechanisms such as version numbers. Optimistic locking is suitable for multi-read application types, which can improve throughput. Redis uses this check-and-set mechanism to implement transactions .
Optimistic locking adds a field called version to the data during data operation. Everyone can get this version of data. For example, in the picture above, you can get the data of v1.0, which is 10000. If the first person is faster, First, the money is reduced by 8,000 yuan, and finally it becomes 2,000 in the database. At this time, the version number of the database is also updated to v1.1. For example, if the second person performs the operation again, he will first check the version number of the current data and the database Are the version numbers in the files consistent? If they are different, the operation cannot be performed.
When performing transaction operations, optimistic locking has been added.
Three characteristics of Redis transactions
- Separate isolation operation
- All commands in a transaction are serialized and executed sequentially. During the execution of the transaction, it will not be interrupted by command requests sent by other clients.
- No concept of isolation level
- The commands in the queue will not be actually executed until they are submitted, because no instructions will be actually executed before the transaction is submitted.
- No guarantee of atomicity
- If a command in the transaction fails to execute, subsequent commands will still be executed without rollback.