Introduction to Redis Transactions

1 What is Redis transaction

Redis provides transactional functionality through multi, EXEC, discard, and watch commands. Redis transactions provide a one-time, sequential mechanism for executing commands, and do not interrupt the transaction to execute other commands. The Redis transaction is somewhat different from the one we often understand that a partial command execution failure in a transaction does not cause the transaction to roll back. The core idea of Redis transactions is to maintain a queue of transactional commands, pre-store all the commands in a transaction to the queue, wait for exec to execute together, or discard empty the queue. 2 redis Transaction Commands

The execution of a transaction is divided into three steps, transaction Initiation, command-in-queue, and transaction execution. 2.1 MULTI (transaction start)

When the REDIS server receives a MULTI command sent by a client, it flags the status of the client as a transaction state (Redis_multi), and the client of the transaction state joins the command queue with the exception of MULTI, EXEC, discard, and watch commands. If there is an error command, it causes the transaction to be canceled. For example:

127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> set name "Shi Ke"
QUEUED
127.0.0.1:6379> Set FirstName "Shi"
QUEUED
127.0.0.1:6379> Err set
(error) Err unknown command ' err '
127.0.0.1:6379 > Get name
QUEUED
127.0.0.1:6379> get firstName
QUEUED
127.0.0.1:6379> exec
( Error) Execabort Transaction discarded because of previous errors.

2.2 EXEC (transaction execution)

When the Redis server receives the client's EXEC command, it iterates through all of the server's transaction commands and executes sequentially, returning the result and changing the client state back to non-transactional. It is important to note that the Redis server does not guarantee that every command will succeed, that successful execution alters the database library state, and does not provide rollback functionality. 2.3 DISCARD (transaction cancellation)

When the Redis server receives the Discard command, it empties the client's transaction command queue and modifies the client state to non-transactional. For example:

127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> set name "Keshi"
QUEUED
127.0.0.1:6379> DISCARD
OK
127.0.0.1:6379> exec
(error) ERR exec without MULTI

2.4 WATCH (monitoring)

You can use the Watch command to monitor a specific key before the transaction starts, and when another client modifies the monitored key, the server will refuse to execute the next transaction on that client. For example:

Redis-cli-1                          redis-cli-2
127.0.0.1:6379> WATCH name
OK
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> Get name
QUEUED
127.0.0.1:6379> Set FirstName "Yang"  127.0.0.1:6379> set name "Yang Li"
QUEUED
127.0.0.1:6379> EXEC
(nil)
127.0.0.1:6379> get firstName
"Shike"
127.0.0.1:6379> get Name
"Yang Li"

3 The acid principle of Redis transactions

The acid of a transaction is the atomicity, consistency, isolation, and persistence of transactions, and Redis transactions guarantee atomicity, consistency, isolation, but not persistence. 3.1 atomicity

The atomicity of a transaction means that a set of operations is either executed entirely or not executed at all. Redis guarantees that a set of data can be executed at the same time or not. However, unlike relational database transaction operations such as MySQL, Redis does not provide a rollback operation where a partial operation failure does not cause the entire transaction to be rolled back. 3.2 Consistency

Transactional consistency refers to the fact that the data in the database conforms to the specifications of the database, and there is no data that does not conform to the specification. Redis guarantees transactional consistency through rigorous error detection.
First, the error back in the queue directly causes the entire transaction to fail, ensuring consistency.
Second, the execution error skips the error command and continues with the other commands.
Third, the server restarts, if there is persistence through the RDB, aof file recovery data, otherwise the database is empty. 3.3 Isolation

Redis transactions do not actually operate the database until they are executed just before the command exists in the operation queue, and all transactions do not affect each other. 3.4 Durability

The persistence of a redis transaction is determined by his persistence policy, and is persistent only if the AOF mode is used and Appendfsync is set to always, for specific reasons see Redis persistence Introduction (http://blog.csdn.net/ sk199048/article/details/50589491)