Shulou(Shulou.com)05/31 Report--

Editor to share with you about Redis transactions support ACID, I believe that most people do not know much about it, so share this article for your reference, I hope you can learn a lot after reading this article, let's go to know it!

What is the ACID of a transaction

As the saying goes, "if you join together, you will die." in order to find the dust beads, the three of them have a clear division of labor and work together to advance and retreat together in order to succeed.

A Transaction is a concurrency control unit, composed of a sequence of operations that are either performed or not performed. [related recommendation: Redis video tutorial]

"is an indivisible unit of work".

When a transaction is executed, it provides a special property guarantee:

Atomicity (Atomicity): multiple operations of a transaction must be completed, or none of them must be completed (how can atomicity of ps:MySQL be realized? Welcome comments in the message area)

Consistency (Consistency): after the completion of transaction execution, the integrity constraints of the database are not broken, and the order before and after the transaction execution is legal data state.

Database integrity constraints include, but are not limited to:

Physical integrity (such as the existence and uniqueness of a row's primary key)

Column integrity (for example, the type, size, and length of fields should meet the requirements)

Foreign key constraint

User-defined integrity (for example, the sum of the balances of the two accounts should remain the same before and after the transfer).

Isolation: operations within a transaction are isolated from other transactions, and transactions executed concurrently cannot interfere with each other.

What is important is the interaction between different transactions, and the strict isolation corresponds to the serializability (Serializable) in the isolation level.

Durability: once the transaction is committed, all changes will be permanently saved to the database, even if the system crashes and restarts the data will not be lost.

Brother Ma, after understanding the specific requirements of ACID, how does Redis implement the transaction mechanism?

How to implement transactions in Redis

The MULTI, EXEC, DISCARD, and WATCH commands are the basis for Redis to implement transactions.

The execution of a Redis transaction consists of three steps:

Open a transaction

Order to join the team

Perform a transaction or discard

Explicitly open a transaction

The client explicitly indicates that a transaction is started through the MULTI command, and subsequent commands are queued and not actually executed.

Order to join the team

The client sends a series of instructions to be executed in the transaction to the server.

It is important to note that although instructions are sent to the server, the Redis instance only temporarily stores this series of instructions in a command queue and does not execute them immediately.

Perform a transaction or discard

The client sends the command to commit or discard the transaction to the server, and the Redis executes the specific instructions sent in the second step or the command to clear the queue, and gives up execution.

Redis only needs to schedule the execution of queue commands when EXEC is called.

Commands saved in the queue in the second step can also be discarded through DISCARD.

Redis transaction case

Execute our sample code: try.redis.io by debugging the website online

Normal execution

Perform a transaction process through MULTI and EXEC:

# Open transaction > MULTIOK# start to define some column instructions > SET "official account: codebyte", "fan 1 million" QUEUED > SET "order"30" QUEUED > SET "number of articles" 666QUEUED > GET "number of articles" QUEUED# actual execution transaction > EXEC1) OK2) OK3) OK4) "666"

We see that the return result of each read-write instruction is QUEUED, indicating that the thank you operation has been temporarily stored in the command queue and has not been actually executed.

When the EXEC command is executed, you can see the specific response data for each instruction.

Abandon transaction

Discard queue commands through MULTI and DISCARD:

# initialization orders > SET "order:mobile" 100OK# Open transactions > MULTIOK# orders-1 > DECR "order:mobile" QUEUED# discard column commands > DISCARDOK# data has not been modified > GET "order:mobile"100"

Brother Ma, can the transaction of Redis guarantee the ACID feature?

That's a good question. Let's analyze it together.

Redis transaction satisfies ACID?

Redis transactions can execute more than one command at a time with three important guarantees:

Batch instructions are queued for temporary storage before executing the EXEC command

After receiving the EXEC command, enter the transaction execution, any command execution in the transaction fails, and the rest of the commands are still executed.

During transaction execution, commands submitted by other clients are not inserted into the sequence in which the current command is executed.

Atomicity

Brother Ma, if an error occurs during the execution of the transaction, is the atomic performance guaranteed?

During a transaction, you may encounter two types of command errors:

The instruction sent is inherently incorrect before the EXEC command is executed. As follows:

Wrong number of parameters

The command name is wrong and a command that does not exist is used

Out of memory (the Redis instance uses the maxmemory instruction to configure the memory limit).

After executing the EXEC command, the command may fail. For example, the data types of commands and operations do not match (List list operations are performed on value of type String)

When executing the EXEC command of a transaction. The failure of the Redis instance caused the transaction execution to fail.

Error report before EXEC execution

When ordering to join the team, Redis will report an error and record the error.

At this point, we can continue to submit commands.

After the EXEC command is executed, Redis refuses to perform all committed command operations and returns the result of the transaction failure.

In this way, all commands in the transaction will no longer be executed, ensuring atomicity.

The following is an example of an error in the instruction queue, resulting in the failure of the transaction:

# Open transaction > MULTIOK# send the first operation in the transaction, but Redis does not support this command. It returns error message 127.0.0.1 ERR unknown command 6379 > PUT order 6 (error) ERR unknown command `PUT`, with args beginning with: `order`, `6`, # send the second operation in the transaction. This operation is the correct command. Redis queues the command > DECR b:stockQUEUED# actually executes the transaction, but there is an error in the previous command. So Redis refuses to execute > EXEC (error) EXECABORT Transaction discarded because of previous errors.

Error report after EXEC execution

When a transaction operation is queued, the data types of the command and operation do not match, but the Redis instance does not check for an error.

However, after the EXEC command is executed, the Redis actually executes these instructions and will report an error.

Knock on the blackboard: although Redis will report an error to the wrong instruction, the transaction will still execute the correct command, so the atomicity of the transaction can not be guaranteed!

Brother Ma, why doesn't Redis support rollback?

In fact, there is no rollback mechanism in Redis. Although Redis provides the DISCARD command.

However, this command can only be used to actively abandon transaction execution and empty the temporary command queue, which does not have the effect of rollback.

Failure occurred during EXEC execution

If AOF logging is enabled by Redis, only part of the transaction will be recorded in the AOF log.

We need to check the AOF log file using the redis-check-aof tool, which removes outstanding transaction operations from the AOF file.

In this way, after we restore the instance using AOF, the transaction operation will not be performed again, thus ensuring atomicity.

A brief summary:

An error is reported when the order joins the queue, and the execution of the transaction will be abandoned to ensure atomicity.

The order to join the team was not wrong, the actual implementation of the Times was wrong, and atomicity was not guaranteed.

The instance fails during the execution of the EXEC command. If the AOF log is turned on, atomicity can be guaranteed.

Consistency

Consistency will be affected by incorrect commands and the timing of instance failures. According to the timing of two dimensions of command errors and instance failures, it can be divided into three situations.

Report an error before joining the team before the implementation of EXEC

Transactions are discarded, so consistency can be guaranteed.

After the implementation of EXEC, the actual execution was wrong.

If there is an error, it will not be executed, the correct instruction can be executed normally, and consistency can be guaranteed.

Instance failure during EXEC execution

The instance will be restarted after a failure, which is related to the method of data recovery. We will discuss whether the instance has enabled RDB or AOF.

If we do not enable RDB or AOF, then, after the instance failure restarts, the data is gone, and the database is consistent.

If we use RDB snapshots, because RDB snapshots are not executed when the transaction is executed.

Therefore, the results of the transaction command operation are not saved to the RDB snapshot, and the data in the database is consistent when the RDB snapshot is used for recovery.

If we use the AOF log and the instance fails before the transaction operation is logged to the AOF log, the database data recovered using the AOF log is consistent.

If only some of the operations are logged to the AOF log, we can use redis-check-aof to clear the completed operations in the transaction, and the database is consistent after recovery.

Isolation

Transaction execution can be divided into two stages: command queue (before EXEC command execution) and command actual execution (after EXEC command execution).

Therefore, in the process of concurrent execution, we analyze these two phases in two ways:

Concurrent operations are performed before the EXEC command, and isolation needs to be ensured by WATCH mechanism

The isolation of concurrent operations can be guaranteed after the EXEC command.

Brother Ma, what is the WATCH mechanism?

Let's focus on the first case: when the EXEC command of a transaction is not executed, the command operation of the transaction is temporarily stored in the command queue.

At this point, if there are other concurrent operations and the same key is modified, it depends on whether the transaction uses the WATCH mechanism.

The function of the WATCH mechanism is to monitor the change of the value of one or more keys before the transaction executes. When the transaction calls the EXEC command to execute, the WATCH mechanism will first check whether the monitored key has been modified by other clients.

If modified, the transaction execution is abandoned to prevent the isolation of the transaction from being broken.

At the same time, the client can execute the transaction again, at this time, if there is no concurrent operation to modify the transaction data, the transaction can be executed normally, and the isolation is guaranteed.

No WATCH.

If there is no WATCH mechanism, the concurrent operation before the execution of the EXEC command reads and writes the data.

When EXEC is executed, the data to be manipulated within the transaction has changed, and Redis does not achieve isolation between transactions.

Concurrent operations are received and executed after EXEC

As for the second case, because Redis executes commands with a single thread, and after the EXEC command is executed, Redis ensures that all commands in the command queue are executed before the subsequent instructions.

Therefore, in this case, concurrent operations do not break the isolation of transactions.

Persistence

If Redis does not use RDB or AOF, then the persistence property of the transaction is certainly not guaranteed.

If Redis uses RDB mode, then, after a transaction is executed, but before the next RDB snapshot is executed, if the instance is down and the data is lost, the data modified by the transaction cannot be guaranteed to be persisted.

If Redis uses AOF mode, there will be data loss because of the three configuration options of AOF mode, no, everysec, and always.

Therefore, the persistence property of the transaction is still not guaranteed.

Regardless of the persistence mode adopted by Redis, the persistence properties of transactions are not guaranteed.

Summary

Redis has some atomicity, but does not support rollback.

Redis does not have the concept of consistency in ACID. (or Redis ignored this when it was designed)

Redis is isolated.

Redis cannot guarantee persistence.

The transaction mechanism of Redis can guarantee consistency and isolation, but not persistence.

However, because Redis itself is an in-memory database, persistence is not a required attribute, and we are more concerned with atomicity, consistency, and isolation.

The situation of atomicity is more complex, when the command syntax used in the transaction is incorrect, atomicity can not be guaranteed, in other cases, the transaction can be executed atomically.

These are all the contents of the article "do Redis transactions support ACID?" Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.