Transaction is an important function of database. Transactions are a series of operations that read and write data. Redis implements transactions through commands such as MULTI, EXEC, and WATCH:

redis> MULTI
OK

redis> SET "name" "mike"
QUEUED

redis> GET "age"
QUEUED

redis> EXEC
1) OK
2) 20
Copy the code

The transaction starts with a MULTI command, then multiple commands are put into the transaction, and finally the transaction is committed to the server by the EXEC command.

Among them:

  1. The execution of the MULTI command marks the beginning of a transaction. You can switch the client running the command from the non-transactional state to the transactional state.
  2. When a client enters a transaction state, if the client sends a command other than EXEC/DISCARD/WATCH/MULTI, the server will not execute the command immediately. Instead, the server will place the command in a transaction queue (FIFO) and return QUEUED to the client.
  3. When the client in the transaction state sends an EXEC command to the server, the EXEC command will be executed by the server immediately, and the server will traverse the transaction queue of the client, execute all the commands saved in the queue, and finally return all the results of executing the command to the client.

Optimistic locking

The WATCH command is an optimistic locking of Redis guaranteed transactions. It monitors the desired number of database keys before the EXEC command is executed, and after the EXEC command is executed, it checks whether the monitored keys are modified. If a key is changed, the server rejects the transaction to ensure the transaction is secure.

The ACID properties

Transactions execute with proprietary property guarantees including Atomicity, Consistency, Isolation and Durability (ACID property). These attributes include requirements for both the results of the transaction and the changes in the data state of the database before and after the transaction. For these four properties, Redis does the following:

atomic

For Redis transactions, all or none of the commands in the transaction queue are executed, so Redis transactions are atomic. The biggest difference between Redis and relational database transactions is that Redis does not support transaction rollback. Even if an error occurs during the execution of a command in the transaction queue, the entire transaction will continue to execute. There are three types of command errors:

  1. Redis will abandon transaction execution to ensure atomicity.
  2. No error was reported when the command entered the team, the actual execution of the error, Redis does not guarantee atomicity;
  3. If the AOF log is enabled, Redis can guarantee atomicity and remove unfinished transactions.

consistency

Transaction consistency means that if the database is consistent before the transaction is executed, it should be consistent after the transaction is executed, regardless of whether the transaction succeeds or not. Transaction consistency is affected by incorrect commands and instance failures:

  1. Redis will abandon transaction execution, database is consistent;
  2. No error is reported when the command is entered into the queue, but an error is reported when it is executed in practice. The commands with errors will not be executed. The correct commands will be executed normally, and the database is consistent.
  3. When an instance fails during EXEC command execution, the database can be consistent regardless of whether AOF or RDB is enabled.

Isolation,

Transaction isolation means that when multiple transactions are executed concurrently, each transaction does not affect the other, and the results produced by the parallel or serial execution of the transaction are identical. Due to the optimistic locking mechanism of Redis, the isolation of transaction execution in parallel state is guaranteed. If the concurrent operation is executed by the server after the EXEC command, it will be as long as the single-thread operation, and the isolation is also guaranteed.

persistence

The persistence of a transaction means that at the end of the transaction, the result of the execution of the transaction has been saved in the permanent storage medium, and the result of the execution of the transaction will not be lost. However, for Redis, there will be data loss regardless of whether RDB or AOF is enabled, so the persistence of transactions cannot be guaranteed.