preface
Because I have read a lot of articles about Redis affairs by big wigs, I have not found the same opinion with myself. Therefore, I write this article mainly to put forward my views on Redis transactions.
What is a transaction
According to baidu Baike, a transaction should have four attributes: atomicity, consistency, isolation and persistence. These four properties are commonly referred to as ACID properties
Then let’s see if Redis can satisfy the four characteristics of ACID.
I’ll start with a few commands for Redis transactions
- Multi: enables a transaction
- Exec: Executes a transaction
- Discard: Cancels a transaction
1. Atomicity
Definition: A transaction is an indivisible unit of work in which all or none of the operations are performed.
The following two cases are demonstrated (compilation and runtime exceptions)
The first type: compiled exceptions
Step 1 Clear all keys
Step 2. Start the transaction
Step 3. Execute a correct command in the transaction
Step 4. Execute a command in the transaction that will report an error at compile time
Step 5. Commit the transaction
This can be seen in the screenshot above
The correct command executed in this step returns QUEUED, indicating that the instruction is QUEUED (but not yet executed).
The compile-time error command executed in this step directly prompts an error
The transaction is cancelled when exec is executed
No. (6) All keys are displayed blank
Conclusion 1. The transaction will be cancelled if a compile error occurs in the transaction. 2. All commands in the transaction will not be executed. 3. In this case, atomicity can be regarded as guaranteed; 4. But in real business, we don’t have a lot of this, but a lot of the second.
Second: runtime errors
Step 1 Clear all keys
Step 2. Set a value ahead of time for demonstration purposes
Step 3. Start the transaction
Step 4. Execute a correct command in the transaction
Step 5. Execute a command in a transaction that will report an error at run time
Step 6. Execute a correct command in the transaction
Step 7. Commit the transaction
Step 8 View the running result
This can be seen in the screenshot above
The commands executed in step (4), step (5), and step (6) all return QUEUED, indicating that the three instructions have entered the queue. Because no command is executed, no error is reported in step (5)
Exec exec exec exec exec exec exec exec exec exec exec exec exec exec
By checking all the keys of Redis, you can also see that there are now three pieces of data
Conclusion 1. If a runtime error occurs in a transaction, the transaction will not be cancelled. 2. All commands in the transaction will be executed, and incorrect commands will not affect the execution of correct commands; 3. In this case, atomicity cannot be guaranteed;
2. Consistency
Definition: a transaction must change the database from one consistent state to another. Consistency is closely related to atomicity.
Here is a demonstration of some scenario
Example: Zhangsan and Lisi each have 1000 pieces. Zhangsan transfers 500 pieces to Lisi. Finally, Zhangsan has 500 pieces left and Lisi has 1500 pieces.
Step 1 Clear all keys
Step 2. Set two values ahead of time for demonstration
Step 3. Start the transaction
Step 4. In the transaction, run the zhangsan command to reduce 500
Step 5. Execute lisi increment 500 command in transaction (but this command simulates runtime exception)
Step 6. Commit the transaction
Step 7 View the running result
This can be seen in the screenshot above
The commands in steps (2) to (5) were executed normally
No. (6) An error message is displayed when executing exec command in this step
Step (7) shows that there is a problem with the result
Conclusion 1. We can predict this result from the above conclusion in the exploration of atomicity. 2. In fact, according to the definition of consistency: “consistency is closely related to atomicity”, we can also guess that it is difficult to guarantee consistency if atomicity cannot be guaranteed; 3. In this case, consistency can not be guaranteed;
3. Isolation
Definition: The execution of a transaction cannot be interrupted by other transactions. That is, the operations and data used within a transaction are isolated from other concurrent transactions, and the concurrent transactions cannot interfere with each other
Here is a demonstration of some scenario
Example: Still take zhangsan as an Example. There are 1000 pieces of zhangsan in transaction 1, 500 pieces of Zhangsan are spent in transaction 1, and 1000 pieces of Zhangsan are saved in transaction 2.
Step 1 Clear all keys
Step 2. Set a value ahead of time for demonstration purposes
Step 3. Enable transactions 1 and 2
Step 4. In transaction 1, run the command to reduce zhangsan by 500 and in transaction 2, run the command to increase Zhangsan by 1000
Step 5. Transaction 2 commits the transaction first, and then transaction 1 commits the transaction
Step 6. View the zhangsan money in transaction 1
This can be seen in the screenshot above
Conclusion 1. Sequence numbers (1) to (6) in REDIS1 and reDIS2 all commands are normally executed without task error; 2. According to the isolation of transaction, zhangsan’s money in transaction 1 should be 500, but due to the influence of transaction 2, zhangsan’s money becomes 1500; 3. In this case, it can be considered that isolation cannot be guaranteed;
4. Durability
Definition: Persistence, also known as permanence, means that once a transaction is committed, its changes to the data in the database should be permanent. Subsequent operations or failures should not affect it in any way
In order to demonstrate the effect, the RBD persistence mode has been modified, as shown in the following figure
So let’s do that
Example: Set three keys in the transaction, then kill the redis service, and restart the redis service to see if the key exists.
Step 1 Clear all keys
Step 2. Start the transaction
Step 3. Set three values
Step 4. Commit the transaction
Step 5. Kill the Redis service
Step 6 restart the Redis service
Step 7 Check whether the key exists
This can be seen in the screenshot above
Conclusion 1. All commands of serial numbers (1) to (7) are normally executed in Redis without task error; 2. If the transaction is persistent, all three keys of set should be saved to disk, but the key in redis is empty. 3. In this case, persistence can not be guaranteed;
The final summary
Through the above case demonstration, it can be seen that redis transactions are difficult to ensure the ACID properties of transactions. So can Redis “transactions” be called transactions?