Redis transactions and ACID attributes

Redis transactions and ACID attributes

In web development, the database is the mainstay and the foundation of everything. In actual development, the relational database MySQL is mainly used. MySQL database can meet the basic needs of small projects, but when the amount of project data and concurrency gradually increase, pure MySQL databases often face huge performance pressure. At this time, the non-relational database Redis made its debut. The Redis database running in memory is simple and easy to use. It saves disk IO, and can reach a query speed of tens of millions of times per second. And a question worth thinking about is: Can such a small Redis support transactions and can it meet ACID attributes? This article will discuss this one by one.

Redis transaction

Like MySQL, Redis also supports transactions. The transaction execution of Redis is related to a queue. MULTI opens to mark the beginning of a transaction block, followed by multiple commands, and ends with an EXEC and executes the transaction block.

As shown below: the following five lines of commands form a transaction and insert three strings into the database

multi
set a aaa
set b bbb
set c ccc
exec

In addition to MULTI and EXEC, Redis also supports DISCARD command to cancel transactions, WATCH command to monitor a key, UNWATCH to cancel monitoring

Isolation

Transaction isolation means that multiple transactions do not interfere with each other during concurrent execution. Redis transactions can be said to be uncontroversial in terms of isolation, because Redis is a single-process, single-threaded application, and all its transactions will be executed serially, so there is no problem of mutual interference.

Atomicity

The atomicity of transactions refers to: a transaction is either all executed successfully, or an error occurs and all fails. Strictly speaking, Redis transactions do not satisfy atomicity.

A Redis transaction consists of multiple commands. If the error is caused by a checkable error, such as a misspelling of the command, the transaction will fail completely.

However, if the error in the Redis transaction is generated during the execution period, Redis will prompt the command to report an error, but it does not roll back, and other commands are still executed successfully. Therefore, Redis transactions do not satisfy atomicity.

Redis developers believe that the rollback mechanism is contrary to Redis's simple and efficient design, and there is no need to develop transaction rollback functions.

Consistency

The consistency of things means that after a transaction is executed, the integrity constraints of the original database are not destroyed. Redis transactions meet atomicity requirements.

In order to illustrate this point, it is necessary to understand the three error conditions that may destroy the consistency of Redis transactions: enqueue errors, execution errors, and server downtime.

1) Enrollment errors: similar to the above spelling errors, they will be checked out when enrolling and cause the failure of the entire transaction. The database will return to the state before the transaction is executed, so the integrity constraints of the database will not be destroyed.

2) Execution error: Execution error will cause the command to fail and will not make any changes to the database, so it will not affect the consistency of things

3) Server downtime: If the server is down during the execution of the transaction, it will be restored to the state before the transaction execution or become a blank database according to the RDB or AOF persistent file after restart, and these two states Are all consistent

Durability (Duaration)

The durability of a transaction means that when a transaction is executed, the impact of the transaction on the database will be permanently saved, even if the server is down, it will not be lost. Redis transactions sometimes satisfy persistence and sometimes do not satisfy persistence, depending on the persistence strategy set:

1) When the server adopts the RDB persistence mode, the BGSAVE command will be called only when certain conditions are met to save the data permanently. If the server is down after a transaction is executed and before the BGSAVE command is called, the transaction result will be lost, so the durability is not satisfied.

2) When the server adopts the AOF persistence mode and appendfsync is set to everysec or no, the persistence operation will be executed once every second or the operating system will decide when to execute it. This leaves the server down to destroy the transaction persistence opportunity.

3) When the server adopts the AOF persistence mode, and appendfsync is set to always, the execution of each instruction will be accompanied by a persistence operation, then the Redis transaction meets the persistence.