Redis transaction use case sharing

First of all, let’s briefly introduce the essence of redis transactions:

The essence of Redis transactions is a set of commands. Transactions support executing multiple commands at one time, and all commands in a transaction will be serialized. During the transaction execution process, the commands in the queue will be executed serially in order, and command requests submitted by other clients will not be inserted into the transaction execution command sequence.

Summary: A redis transaction is a one-time, sequential, and exclusive execution of a series of commands in a queue.

Redis transactions have no concept of isolation level:

Batch operations are put into the queue cache before sending the EXEC command and will not be actually executed, so there are no queries within the transaction to see. Updates in the transaction cannot be seen by queries outside the transaction.

Redis does not guarantee atomicity:

In Redis, a single command is executed atomically, but transactions do not guarantee atomicity and there is no rollback. If any command in the transaction fails to execute, the remaining commands will still be executed.

Three stages of Redis transactions:

Start transaction command and queue to execute transaction

Redis transaction related commands:

　watch key1 key2...: Monitor one or more keys. If the monitored key is changed by other commands before the transaction is executed, the transaction will be interrupted (similar to optimistic locking)

　multi: Mark the beginning of a transaction block (queued)

　exec: Execute the commands of all transaction blocks (once exec is executed, the previously added monitoring locks will be canceled)

discard: Cancel the transaction and abandon all commands in the transaction block

Unwatch: Cancel watch’s monitoring of all keys

Redis transaction use case:

(1)Normal execution

（ 2) Abandon the transaction

(Learning video sharing: redis video tutorial)

(3) If there is a command in the transaction queue sexual error (similar to java compilation error), when executing the EXEC command, all commands will not be executed

(4) If there is a syntax error in the transaction queue (Similar to Java's 1/0 runtime exception), when executing the EXEC command, other correct commands will be executed, and the wrong command will throw an exception.

(5) Use watch

Case 1: Use watch to detect balance, the balance data does not change during the transaction, and the transaction is executed successfully

Case 2: Use watch to detect balance. After opening the transaction (marked 1), perform the operation marked 2 in a new window, change the value of balance, and simulate other clients during transaction execution. Change the data monitored by the watch, and then execute the command marked 1. After executing EXEC, the transaction was not executed successfully.

Once EXEC is executed to start the execution of a transaction, WARCH's monitoring of variables will be canceled regardless of whether the transaction is executed successfully.

Therefore, when the transaction execution fails, you need to re-execute the WATCH command to monitor the variables and start a new transaction for operation.

Summary:

The watch instruction is similar to optimistic locking. When the transaction is committed, if the value of any KEY among the multiple KEYs monitored by the watch has been changed by other clients, use EXEC to execute the transaction. , the transaction queue will not be executed, and a Nullmulti-bulk response is returned to notify the caller that the transaction execution failed.

Related recommendations: redis database tutorial

The above is the detailed content of Redis transaction use case sharing. For more information, please follow other related articles on the PHP Chinese website!