Preface#
Today, when learning about redis, I found that the transaction feature of redis cannot be rolled back. That is, when executing a transaction, if a command in the middle fails, it will not roll back to before the transaction, but continue to execute.
What? What? So, what's the point of transactions if there's no atomicity, no consistency?
According to the information I searched for and some thinking, I summarized it a bit, which may not be comprehensive.
Performance Optimization#
Since transactions send all commands to the server at once and execute them all at once, the performance is higher.
Although, I think this small performance optimization is not very useful
Data Consistency in Concurrent Environments#
Since multiple clients may operate on the same redis instance at the same time, transactions can ensure that they are not interrupted during execution, so although it cannot guarantee the consistency of data within the transaction, it can ensure the consistency of data in concurrent environments.
Simple and Efficient#
We found that after learning so many redis commands, it seems that there are hardly any commands that will throw an error. Even if you enter the wrong key, it will just return nil, so only when there is a syntax error in your redis command will it throw an error.
So, there is no need to support rollback, making redis simpler and more efficient.