Today we take a look at the Redis transaction. The transaction is like a big housekeeper, regulating data operations so that the data will not be confused.
- What is it?
You can execute multiple commands at once, essentially a set of commands. All commands in a transaction will be serialized, serialized and executed in order without being inserted by other commands, and no jamming is allowed. - What can you do? In
a queue, execute a series of commands in a one-time, sequential, and exclusive manner. - Transaction command
DISCARD: Cancel the transaction and give up executing all commands in the transaction block.
EXEC: Execute all commands in the transaction block.
MULTI: Mark the beginning of a transaction block.
UNWATCH: Cancel the monitoring of all keys by the WATCH command.
WATCH key …: Monitor one (or more) keys. If this (or these) keys are changed by other commands before the transaction is executed, the transaction will be interrupted.
After a transaction block is opened, when adding a command to the queue, if an error is reported when adding, the execution will fail as a whole. If there is no error when adding, then the error will not affect the execution of other commands. Other commands It will execute normally.
Pessimistic lock, as the name implies, is very pessimistic. Every time you get data, you think that someone else will modify it, so every time you get the data, you will lock it, so that if someone wants to get the data, it will block until it gets the lock. Many of these locking mechanisms are used in traditional relational databases, such as row locks, table locks, etc., read locks, write locks, etc., all of which are locked before performing operations.
Optimistic lock, as the name implies, is very optimistic. Every time I get the data, I think that others will not modify it, so it will not be locked, but when updating, it will judge whether others have updated the data during this period, and it can be used. Mechanisms such as version numbers. Optimistic locking is suitable for multi-read application types, which can improve throughput. Optimistic locking strategy: The submitted version must be greater than the current version of the record before the update can be performed.
The WATCH instruction is similar to optimistic locking. When the transaction is committed, if the value of the key has been changed by other clients, for example, a list has been pushed/popped by other clients, the entire transaction queue will not be executed. Multiple keys are monitored before the transaction is executed through the WATCH command. If any key value changes after the WATCH, the transaction executed by the EXEC command will be abandoned, and a Nullmulti-bulk response will be returned to notify the caller that the transaction failed. - Three phases of transaction
Open: start a transaction with MULTI Enqueue: Enqueue
multiple commands into the transaction. These commands will not be executed immediately after receiving these commands, but will be executed in the transaction queue waiting to be
executed: triggered by the EXEC command Affairs - Three characteristics of the transaction
Separate isolation operation: All commands in the transaction will be serialized and executed in order. During the execution of the transaction, it will not be interrupted by the command request sent by other clients.
There is no concept of isolation level: the commands in the queue will not be actually executed before they are submitted, because no instructions will be actually executed before the transaction is submitted, and there is no query within the transaction to see the updates in the transaction. Queries outside the transaction can't see this extremely headache problem.
Atomicity is not guaranteed: If a command fails to execute in the same transaction in redis, the subsequent commands will still be executed without rollback.
