Preface#
Today, when learning about Redis, I found that Redis's transaction feature cannot rollback. In other words, when executing a transaction, if a command in the middle fails, it will not rollback to the state before the transaction but continue to execute.
What? What? Then what's the use of transactions if there's no atomicity, no consistency?
Based on my research and thinking, I have summarized it a bit, which may not be comprehensive.
Isolation#
Although rollback is not supported, there is still isolation in a concurrent environment. watch can achieve something similar to optimistic locking, and conflicts will be checked at the end of exec.
Simple and Efficient#
We found that after learning so many Redis commands, it seems that hardly any command will throw an error. Even if the key you input is wrong, it will just return nil. Only when there is a syntax error in your Redis command or when using the wrong type of key will an error be thrown, and these errors should be discovered during development.
Therefore, without rollback, Redis's internals can be simpler and more efficient, thereby improving performance.
So, there is no need to support rollback, making Redis even simpler and more efficient.