Detailed Redis transaction

Redis transaction concept

Redis implements transaction functions through commands such as MULTI, EXEC, and WATCH . Transaction provides a mechanism to package multiple command requests, and then execute multiple commands one-time and sequentially. During the execution of the transaction, the server will not interrupt the transaction and execute the command requests of other clients instead. All the commands in the transaction are executed, and then the command requests from other clients are processed.

The following is the process of a transaction execution. The transaction first starts with a MULTI command, then puts multiple commands into the transaction, and finally the EXEC command commits the transaction to the server for execution:

Three stages of redis transaction

A transaction usually goes through the following three stages from the beginning to the end: the beginning of the transaction, the enqueue of the command, and the execution of the transaction.

Let's understand the implementation principle of the three stages of redis transaction:

1. Transaction start
   The execution of the MULTI command marks the beginning of the transaction. The MULTI command can switch the client executing the command from a non-transactional state to a transactional state. This switch is done by turning on the REDIS_MULTI flag in the flags attribute of the client state . , The implementation of the MULTI command can be represented by the following pseudo code:
   

2. Command enqueue
   When a client is in a non-transactional state , the command sent by the client will be executed by the server immediately . The difference is that when a client switches to the transactional state, the server will send it according to the client Different commands perform different operations:

   • If the command sent by the client is one of the four commands EXEC, DISCARD, WATCH, MULTI, the server immediately executes this command.
   • If the command sent by the client is one of the four commands EXEC, DISCARD, WATCH, MULTI, the server immediately executes this command.
     On the contrary, if the command sent by the client is a command other than the four commands EXEC, DISCARD, WATCH, and MULTI, the server does not execute this command immediately, but puts the command in a transaction queue , and then sends it to the client The end returns a QUEUED reply.

   The transaction queue is an array. The transaction queue saves the commands entered into the queue in a first- in first-out (FIFO) manner . The commands that enter the queue first will be placed in front of the array, and the commands of the later team will be placed in the array. Behind.

   The process by which the server judges whether the command should be enqueued or executed immediately can be described by the following flowchart.
   

3. Transaction execution
   When a client in a transaction state sends an EXEC command to the server, the EXEC command will be executed by the server immediately. The server will traverse the client's transaction queue, execute all the commands stored in the queue, and finally return all the results of executing the commands to the client.

Four characteristics of redis transactions (ACID)

1. Does redis support atomicity?
   The atomicity of a transaction means that the database executes multiple operations in the transaction as a whole, and the server either executes all operations in the transaction or does not execute one operation. For the transaction function of Redis, all commands in the transaction queue are executed, or none of them are executed. Therefore, Redis transactions are atomic .

2. Does redis support consistency?
   Transaction consistency means that if the database is consistent before the transaction is executed, then after the transaction is executed, the database should still be consistent regardless of whether the transaction is executed successfully. Redis transactions support consistency .

3. Does redis support isolation?
   Transaction isolation refers to the fact that even if multiple transactions are executed concurrently in the database, each transaction will not affect each other, and the results of the transaction executed in the concurrent state and the transaction executed serially are exactly the same. Because Redis uses a single-threaded way to execute transactions (and commands in the transaction queue), and the server guarantees that the transaction will not be interrupted during the execution of the transaction, therefore, Redis transactions always run in a serial manner, and Transactions are always isolated .

4. Does redis support persistence?
   The durability of a transaction means that when a transaction is executed, the result of executing the transaction has been saved to a permanent storage medium (such as a hard disk), even if the server is shut down after the transaction is executed, the result of executing the transaction It will not be lost.
   Because Redis transactions are simply a set of Redis commands wrapped in a queue, Redis does not provide any additional persistence functions for transactions, so the durability of Redis transactions is determined by the persistence mode used by Redis :

   1. When the server is operating in the non-persistent memory mode, the transaction is not durable: once the server is down, all server data including transaction data will be lost.
   2. When the server is operating in the RDB persistence mode, the server will only execute the BGSAVE command to save the database when the specific saving conditions are met, and the asynchronous execution of BGSAVE cannot guarantee that the transaction data will be saved in the first time In the hard disk, transactions in the RDB persistence mode are not durable either.
   3. When the server is running in AOF persistence mode, and the appendfsync option value is always, the program will always call the sync function after executing the command to actually save the command data to the hard disk, so the transaction under this configuration It is durable.
   4. When the server is running in AOF persistence mode and the appendfsync option value is everysec, the program will synchronize the command data to the hard disk once every second. Because the downtime may happen within one second of waiting for synchronization, which may cause transaction data loss, transactions in this configuration are not durable.
   5. When the server is running in AOF persistence mode and the appendfsync option is no, the program will leave the operating system to determine when to synchronize the command data to the hard disk. Because transaction data may be lost while waiting for synchronization, transactions in this configuration are not durable.

5. Does redis transaction support rollback?
   not support

Do you understand the watch command in redis?

The WATCH command is an optimistic locking (optimistic locking), it can monitor any number of database keys before the EXEC command is executed, and when the EXEC command is executed, check whether at least one of the monitored keys has been modified, if it is If this is the case, the server will refuse to execute the transaction and return to the client an empty reply representing the failure of the transaction.

For example:
The principle of the watch command:
each Redis database stores a watched_keys dictionary, the key of this dictionary is a database key monitored by the WATCH command, and the value of the dictionary is a linked list, which records all monitoring The client of the corresponding database key; by executing the WATCH command, the client can associate with the monitored key in the watched_keys dictionary.

For the specific implementation principle of the watch command, please refer to "Redis Design and Implementation"

to sum up

• Transaction provides a mechanism for packaging multiple commands and then executing them in an orderly manner. Multiple commands will be enqueued into the transaction queue, and then executed in a first-in-first-out (FIFO) order.
• The transaction will not be interrupted during execution, and the transaction will end after all commands in the transaction queue have been executed.
• The transaction with the WATCH command will associate the client and the monitored key in the watched_keys dictionary of the database. When the key is modified, the program will turn on the REDISDIRTY_CAS flag of all clients that monitor the modified key.
• Only when the client's REDIS_DIRTY_CAS flag is not turned on, the server will execute the transaction submitted by the client, otherwise, the server will refuse to execute the transaction submitted by the client.
• Redis transactions always have the atomicity, consistency and isolation in ACID. When the server is running in AOF persistence mode and the appendfsync option value is always, the transaction is also durable.