The so-called transaction (Transaction) refers to a series of operations performed as a single logical unit of work. The transaction must meet the ACID principles (atomicity, consistency, isolation, and durability). To put it simply, a transaction is actually packaging a set of operations (or commands) as a whole. These operations will be executed in sequence during transaction processing and the results will be returned. If any one of the links fails, all operations will be rolled back.
The realization of transactions in Redis mainly relies on the following commands to achieve: 
Redis transactions usually go through three stages from beginning to end:
1. The start of the transaction
2. The order to join the team
3. The execution of the transaction
The following is the simplest Redis transaction process: the 
first step is similar to other relational databases, and a transaction needs to be opened. The command in Redis is as follows: 
Redis uses the MULTI command to mark the beginning of a transaction, which can be understood as a traditional relationship In the BEGIN TRANCATION statement in the type database, Redis switches the client executing the command from a non-transactional state to a transactional state. This switch is completed by turning on the REDIS_MULTI flag in the flags attribute of the client state. Let’s look at the corresponding part in Redis Source code implementation: 
In the client that opens the transaction identifier, these commands will be temporarily stored in a command queue, and will not be executed immediately due to user input.
The second step is to execute the roadbed within the transaction, that is, the real business logic:
The last stage is to commit the transaction (or roll back the transaction):
These two commands can be regarded as equivalent to COMMIT/ROLLBACK statements in relational databases.
It should be noted here that after the client has opened the transaction identification, only the commands: EXEC, DISCARD, WATCH, MULTI will be executed immediately, and other command servers will not be executed immediately, but will put these commands into a transaction queue. Inside, it then returns a QUEUED reply to the client; the Redis client has its own transaction state, which is stored in the client state mstate attribute. The structure type of mstate is multiState. Let’s look at the definition of multiState: 
let’s look at it again. The structure of the structure type multiCmd: The 
transaction queue is stored in a first-in-first-out method. The commands that are entered first will be placed in front of the array, and the commands that entered the queue later will be placed at the back of the array.
When the client with the transaction identifier sends the EXEC command, the server will execute the command in the transaction queue corresponding to the client. Let’s take a look at the implementation details of EXEC: 
Finally, let’s review the characteristics of the transaction itself. In the traditional relationship The transaction in the database must rely on ACID to ensure the reliability and security of the transaction. In Redis, the transaction always has consistency (Consistency) and isolation (Isolation), and when Redis runs in a specific persistence mode The transaction also has durability (Durability); but atomicity is not always guaranteed. In the normal state, all commands of a transaction can be executed in accordance with the principle of atomicity, but errors are encountered in the middle of the execution. Will not roll back, but continue to execute subsequent commands, as follows:
If it fails at set k2 v2, set k1 has succeeded and will not be rolled back, and set k3 will continue to execute; the biggest difference between Redis transactions and traditional relational database transactions is that Redis does not support transaction rollback mechanisms, even if transactions An error occurs during the execution of a command in the queue, and the entire transaction will continue to be executed until all the commands in the transaction queue are executed. Let's look at the following example: 
The author of Redis explains in the transaction function document , Transaction rollback is not supported because this complex function does not conform to the simple and efficient design theme pursued by Redis, and he believes that during the execution of Redis transactions, errors are usually caused by programming errors, and such errors usually only Appears in the development environment, but rarely in the actual production environment, so he believes that there is no need to develop a transaction rollback function for Redis. So when we are discussing Redis transaction rollback, we must distinguish when the command is wrong.
Linux, C/C++ technology exchange group: [960994558] I have compiled some good learning books, interview questions from big companies, and popular technology teaching video materials to share in it (including C/C++, Linux, Nginx, ZeroMQ, MySQL) , Redis, fastdfs, MongoDB, ZK, streaming media, CDN, P2P, K8S, Docker, TCP/IP, coroutine, DPDK, etc.), you can add it yourself if you need it! ~The
above deficiencies are welcome to point out and discuss.