Redis - Transactions

I. Overview

Like traditional relational databases, Redis also supports transactions. Redis transactions can be implemented through commands such as MULTI/EXEC/DISCARD/WATCH.

2. ACID characteristics of transactions

1). Atomicity: The commands in the transaction are either all executed or none of them are executed.

The biggest difference between Redis transactions and traditional relational database transactions is that Redis transactions do not support rollback. Even if an error occurs during the execution of a command in the transaction queue, the entire transaction will continue to be executed, knowing that all commands in the transaction queue are executed. complete.

So what is the advantage of not supporting rollback for Redis: there is no need to support rollback, and the internals of Redis can be guaranteed to be simple and fast.

Is it reasonable to not support rollback: reasonable, the commands in the transaction queue will only fail due to the wrong syntax of the command during the execution process, and the failed command is caused by programming. These errors should be found during the development process, not Should be present in a production environment.

2). Consistency: The database is consistent before the transaction is executed. After the transaction is executed, the database should be consistent regardless of whether the transaction succeeds or fails.

"Consistent" means that the data conforms to the definition and requirements of the database itself, and there is no illegal or invalid erroneous data. Redis ensures transaction consistency through careful error detection and simple design (see this page for details: 4)

3). Isolation: Each transaction will not affect each other, and the results of executing transactions in a concurrent state and in a serial state are exactly the same.

4). Persistence: When the transaction is executed, the result saved in the database will not be lost.

Without a persistence mechanism, the transaction department is persistent: data is lost after the server is stopped and restarted.
Under the RDB mechanism, data set snapshots are only saved under certain conditions, and there is no guarantee that the data will be saved on the hard disk at the first time.
Under the AOF mechanism, when appendfsync = always, the program will always call the synchronization function after executing the command, and store the command data in the hard disk. In this case, the transaction is persistent.
Under the AOF mechanism, when appendfsync = everysec, the program will synchronize the data to the hard disk every second. Because the downtime may occur within the second after the command is executed but not yet synchronized, this will cause transaction data loss, so it is not durable.
Under the AOF mechanism, appendfsync = no, and the operating system decides when to synchronize data to the hard disk. Because transaction data may be lost in the process of waiting for synchronization, this will cause transaction data to be lost, so it is not durable.

3. Usage of related commands

1). MULTI and EXEC: MULTI is used to start a transaction and always returns ok. After MULTI is executed, the following commands will not be executed temporarily, but will be stored in the queue. After EXEC is executed, the commands in the queue will be executed sequentially. Examples are as follows:

2). DISCARD always returns ok, the transaction queue will be emptied, and the transaction will be abandoned. Examples are as follows:

3). WATCH command (want to see this page: 5)

4. How Redis handles errors in transactions

How Redis handles errors in transactions to ensure database "consistency":

1). Enqueue error

Possible reasons: The command does not exist, the command format is incorrect, etc.

Processing method: Redis will record the command that fails to enter the queue. When exec is called, it will automatically refuse to execute and give up the transaction.

An example is as follows: INCR mykey 1 failed to enqueue because the command format is incorrect.

2). Execution error

Possible reasons: Command syntax error (cannot be detected when enqueuing, and an error will be reported only when executing, for example, the command to process a set in a transaction is used on a string).

Processing method: The execution of the command in the transaction fails, and the next command continues to be executed until the execution of the command in the transaction queue ends.

The example is as follows: LPOP mykey reports an error, which works on the list type and cannot be used for strings; however, it does not affect the execution of subsequent commands, and the +1 operation is still successfully executed.

3). Server downtime

If the server is running in non-persistent mode, the database after restart is blank, and the blank database is always consistent.
If the server is running in RDB mode, the existing RDB files can be used to restore the database to a consistent state. If the RDB file cannot be found, the database after restart is blank, and the blank database is always consistent.
If the server is running in AOF mode, data can be recovered from the existing AOF file, restoring the database to a consistent state. If the AOF file cannot be found, the database after restart is blank, and the blank database is always consistent.

To sum up, server downtime does not affect database consistency.

5. WATCH command and optimistic locking

The return value of the WATCH command is always ok.

The WATCH command itself is an optimistic lock. It can monitor a certain number of keys before the EXEC command is executed, and when EXEC is executed, check whether these keys have been modified. If so, the server refuses to execute the transaction. Examples are as follows:

time	Client A	Client B
T1	WATCH name
T2	MULTI
T3	SET name aa
T4		SET name bb
T5	EXEC

When client A executes the transaction, it finds that the value of name has been modified, so the server refuses to execute the transaction.

How to unmonitor the key:

WATCH's monitoring of the key takes effect from the time WATCH is called until EXEC is called. When EXEC is called, regardless of whether the transaction is executed or not, it will cancel the monitoring of the key.
In addition, monitoring is also canceled when the client is disconnected.
Use UNWATCH without parameters to unwatch all keys.