Redis Basics (2): Transaction Mechanism

1. What is the transaction mechanism?

Transaction (transaction) is a unique term for computers. It generally refers to a single logical work unit, which is composed of a series of operations. When these operations are executed, they are either executed successfully or not executed to prevent the inconsistency of data results. .
In short, a transaction is an indivisible logical unit of work. In order to measure whether a unit of work has transaction capabilities, four characteristics need to be met: ACID, namely atomicity (Atomicity, or indivisibility), consistency (Consistency), isolation (Isolation, also known as independence), persistence ( Durability).

• Atomicity: All operations in a transaction are either completed or not completed, and will not end in a middle link. If an error occurs during the execution of the transaction, it will be rolled back (Rollback) to the state before the transaction started, as if the transaction had never been executed.

• Consistency: Before the transaction starts and after the transaction ends, the integrity of the database is not violated. This means that the written data must fully comply with all the preset rules, which includes the accuracy of the data, seriality, and the subsequent database can spontaneously complete the scheduled work.

• • Entity integrity, unique primary key exists
• • Column integrity: field type, field length, etc. comply with all preset rules
• • foreign key foreign key constraint
• • User-defined integrity (for example, before and after the user pays for shopping, the sum of the merchant's income and the user's balance remains unchanged)

• Isolation: The ability of the database to allow multiple concurrent transactions to read, write and modify its data at the same time. Isolation can prevent data inconsistency caused by cross-execution when multiple transactions are executed concurrently. Transaction isolation is divided into different levels, including read uncommitted (read uncommitted), read committed (read committed), repeatable read (repeatable read) and serialization (Serializable).

• Durability: After the transaction processing is completed, the modification to the data is permanent and will be persisted to the hard disk, even if the system fails, it will not be lost.

2. How to implement the transaction mechanism in Redis mode?

Redis supports the transaction mechanism, and its key commands for implementing transactions include:

MULTI、EXEC、DISCARD 、 WATCH

• MULTI starts a transaction, always returns OK
• EXEC commits the transaction
• DISCARD abandons the transaction (that is, abandons the commit execution)
• WATCH monitoring
• The QUEUED command is added to the execution queue. When no action is performed, it is added to the Queue first.

According to the above command, the execution process of Redis transaction consists of three steps:

• Open transaction: MULTI
• Command enqueue: QUEUE
• Execute transaction or discard: EXEC or DISCARD

2.1 Explicitly start a transaction

The client explicitly opens a transaction through the MULTI command, and the subsequent operations will be temporarily cached in the Queue, but not executed immediately.

2.2 Put the command into the queue Queue

The client side sends a series of operation instructions to be executed in the transaction to the service side. After the Redis server instance receives the command, it does not execute it immediately, but temporarily stores it in the command queue.

2.3 Execute transaction or discard

When the commands sent by the client to the server are all ready, it can send a command to submit the transaction or discard the transaction. If it is executed, it will operate the specific command in the queue. If it is discarded, it will clear the queue command.

• EXEC: execute the instructions in the queue
• DISCARD: Discard commands saved in the queue

2.4 EXEC command execution example

Executing a transaction process via MULTI and EXEC:

#开启事务
> MULTI
OK
# 定义一系列指令
> set 'name' 'brand'
QUEUED
> set 'age' 18
QUEUED
> INCR 'age'
QUEUED
> GET 'name'
QUEUED
> GET 'age'
QUEUED
# 实际执行事务
> EXEC
# 获取执行结果
1) OK
2) OK
3) 19
4) "brand"
5) "19"

It can be seen from the above that the return result of each read and write command is QUEUED, which means that these operations are only temporarily stored in the command queue and are not actually executed.
When the EXEC command is sent, it is actually executed and the result is obtained.

2.5 DISCARD command: give up the transaction

Discard execution via MULTI and DISCARD, emptying the instruction queue:

# 初始化订数据
> SET 'name' 'brand'
OK
> SET 'age' 18
OK
# 开启事务
> MULTI
OK
# 数据增量1
> INCR 'age'
QUEUED
# 丢弃
> DISCARD
OK
# 执行结果是增量前的数据
> get 'age'
"18"

2.6 Transaction rollback due to command error

Embodies atomicity, and when a failure occurs, either the execution is successful or the execution fails

# 开启事务
> MULTI
OK
# 初始一个数据
> SET 'age' 18
OK
# 对该数据进行更新，但Redis不支持该命令，返回报错信息
> UPD 'age' 17
(error) ERR unknown command `UPD`, with args beginning with: `age`, `17`,
# 继续发送一个指令 ，降低age的值，该指令是正确的
> DECR 'age'
QUEUED
# 执行exec，但是之前有错误，所以Redis放弃了事务，不再执行
> EXEC
(error) EXECABORT Transaction discarded because of previous errors.

3. What attributes can the Redis transaction mechanism achieve?

Similar to MySQL transactions, Redis transactions can execute multiple instructions at one time, and these multiple instructions are guaranteed by the following methods:

• Before the EXEC command is executed, all commands are temporarily stored (Queued) in the queue;
• After receiving the EXEC command, the Server starts to execute the transaction. Some commands in the transaction fail to execute, and the rest of the commands are still executed;
• When the transaction is executed, it has isolation, and the instructions executed by other clients will not interfere with the execution order of the current instruction.

3.1 Atomicity

In the process of transaction execution, you may encounter these kinds of command execution errors:

• Before executing the EXEC command, the command itself is wrong:
• • Error caused by inconsistent number of parameters
• • Wrong composition of command name, use of non-existent or wrong command: such as 'UPD' above
• • Exceeded the MaxMemory memory limit, resulting in insufficient memory
• After the execution of the EXEC command, the failure caused by the unreasonable operation of the command. For example, the data type does not match (the operation such as INCR or DECR is performed on the value of String type)
• When executing the EXEC command of the transaction, the failure caused by the instance failure is relatively rare.

3.1.1 Error reported before EXEC execution

An error before execution means that when the command is enqueued (Queue), Redis will find and record the error.
Even after executing the EXEC command, Redis will refuse to execute all commands in the command queue and return the result of transaction failure.
In this way, all instructions will not be executed, maintaining atomicity. The following is an example of an error report when an instruction is queued, which is consistent with the above example:

# 开启事务
> MULTI
OK
# 初始一个数据
> SET 'age' 18
OK
# 对该数据进行更新，但Redis不支持该命令，返回报错信息
> UPD 'age' 17
(error) ERR unknown command `UPD`, with args beginning with: `age`, `17`,
# 继续发送一个指令 ，降低age的值，该指令是正确的
> DECR 'age'
QUEUED
# 执行exec，但是之前有错误，所以Redis放弃了事务，不再执行
> EXEC
(error) EXECABORT Transaction discarded because of previous errors.

3.1.2 Error reported after EXEC execution

This is exactly the opposite of the above situation. When the command is entered into the Queue, although the type of the command does not match, it is not checked out during precompilation.
Only after the EXEC command, the error will be reported when the instruction is actually executed. Other correct instructions will still execute successfully, and atomicity is not guaranteed. Refer below:

# 开启事务
> MULTI
OK
> set age 18
QUEUED
> set name 'brand'
QUEUED
> INCR age
QUEUED
# 这边对String类型进行DECR，没有报错，但是在执行指令的时候会报错误
> DECR name
QUEUED
# 执行，会发现其他三条执行执行成功，只有一条执行失败，返回报错信息
> EXEC
1) OK
2) OK
3) 19
4) ERR value is not an integer or out of range
# 查看结果
> get name
"brand"
> get age
"19"

3.1.3 Instance failure occurs during EXEC execution

AOF logs can be used to remove unfinished transaction operations from the AOF logs, and then they will not be executed again when AOF is used for recovery, so as to ensure the atomicity of the entire operation.
This requires Redis to enable the persistence capability of AOF logs.

3.1.4 Summary of the above-mentioned error characteristics

• If an error is reported when an instruction is queued (as long as one of all instructions is not QUEUED), transaction execution will be abandoned to ensure atomicity. Such as 3.1.1
• No error is reported when the instruction is queued (all instructions are QUEUED), but an error is reported when EXEC is actually executed, and atomicity is not guaranteed. Such as 3.1.2
• If a failure occurs during EXEC execution, atomicity can be guaranteed if the AOF log is enabled. Such as 3.1.3

3.2 Consistency

Similar to atomicity, consistency will be affected by incorrect instructions, execution exceptions, Redis failures, etc., mainly in the following situations:

• An error is reported when the instruction is queued, and the execution of the transaction is abandoned, so consistency can be guaranteed.
• When the instruction is put into the queue, it is being generated, and an error is reported when the EXEC is actually executed, but the error part will not be executed, and the correct instruction is still executed normally, and the consistency can also be guaranteed.
• There are several types of Redis instance failures:
• • If persistence is not enabled, the data will be cleared after the fault restarts, and the results are consistent.
• • RDB snapshot: The results of transaction command operations are not saved to the RDB snapshot, so the data results are consistent during recovery.
• • AOF log: When a failure occurs, use redis-check-aof to clear the corresponding operations in the transaction, and the database will remain consistent after recovery.

3.3 Isolation

From the perspective of isolation, the timing of transaction execution can be divided into two types:

• One is that the operation is performed before EXEC (during pure enqueue), at this time, the mechanism of WATCH is used to ensure
• The other is after starting to execute EXEC (actually starting to execute the command), at this time itself has isolation.

3.3.1 Whether there is any change in the monitoring object of WATCH

If there is a change before and after, it means that it has been modified. At this time, the transaction execution is abandoned to prevent the isolation of the transaction from being destroyed.

3.3.2 Sequence operations, concurrent operations after EXEC

Redis operation commands are executed in a single thread, so after the EXEC command is executed, other operations will not be messed up, and Redis will ensure that all commands in the command queue are completed.
Subsequent commands are executed, so concurrent operations in this mode will not break the isolation of transactions. It has a natural isolating ability.

3.4 Persistence

Because of the persistence feature of Redis, there are three possibilities as follows:

• If the RDB snapshot or AOF log is not enabled, the transaction must not have the persistence capability.
• RDB snapshot mode: As we talked about in the article on Redis persistence, RDB has snapshot gaps, and transaction execution will not be guaranteed between snapshots.
• AOF log: no matter whether the log persistence option is no, everysec or always, there will be data loss, so it cannot be fully guaranteed.
  So no matter what persistence mode Redis adopts, the persistence properties of transactions cannot be fully guaranteed.

Four. Summary

• Redis has certain atomicity, but does not support rollback. DISCARD is mainly responsible for clearing the instruction list and giving up the operation.
• Redis is capable of consistency
• Redis has the ability to isolate
• Redis cannot guarantee durability