What is it
You can execute multiple commands at once, which is essentially a collection 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.
Execute multiple redis commands at once.
What can you do
In a queue, a series of commands are executed in a one-time, sequential, and exclusive manner.
How to play
The MULTI command is used to start a redis transaction. This command will always reply OK (I don't know if it can succeed). At this time, the user can execute multiple commands at once instead of one by one . Redis enqueues them, all commands will be called
DISCARD by EXEC command to abandon batch operation .
Common commands
| command | description |
|---|---|
| DISCARD | Cancel the transaction and give up executing all the 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 [key …] | Monitor one (or more) key. If this (or these) keys are changed by other commands before the transaction is executed, the transaction will be interrupted. |
Case
Normal execution
Abandon transaction
Everyone even sits on
a mistake, everybody even sits without executing
Unjust creditor
Regarding this question, how does
redis support transactions understand redis is partial support for transactions, in this part, the right execution, the wrong execution
case:watch monitoring
Pessimistic lock/optimistic lock/CAS(Check and set)
Pessimistic Lock (Pessimistic Lock), as the name suggests, is very pessimistic. Every time you get the data, you think that others will modify it, so every time you get the data, you will lock it, so that others want to get the data and block until it gets it. To the lock. Many such locking mechanisms are used in traditional relational databases, such as row locks, table locks, etc., read locks, write locks, etc., which are all locked before operations.
Table lock: lock the entire table. But this table may have many pieces of data. At this time, a process needs to make a wide range of changes, which will cause more and more threads to be queued.
Row lock: carry out on each record locking
Optimistic locking
Optimistic locking (Optimistic Lock), by definition, is very optimistic, pick up data every time that others are not modified, so it will not be locked, but the update time It will be judged whether others have updated this data during this period, and mechanisms such as version number can be used. Optimistic locking is suitable for multi-read application types, which can improve throughput.
Optimistic lock strategy: The submitted version must be greater than the current version of the record to perform the update.
Optimistic lock is not blindly optimistic. For example, Zhang San changed the WeChat account , and Li Si had the qq number, and proceeded at the same time. 3. After changing the WeChat account, submit it. At this time, the version number is changed from 1 to 2, and Li Si also submits after changing it. At this time, it changes from 1 to 3, and an exception will be reported and revised.
Optimistic locking is generally used at work
Initialize the available balance and owed credit card
No tampering, monitor first and then enable multi to ensure that the two amount changes are in the same transaction
While monitoring, it was found that another transaction modified the shared data, causing the transaction to fail.
Before modifying the data, you need to lock the watch, otherwise it will cause an error. If someone modifies my data, I will report an exception.
Tampering
The key is monitored, if the key is modified, the execution of the next transaction will fail
unwatch
Cancel the monitoring of all keys by the watch command.
Once the monitoring lock added before exec is executed, it will be cancelled.
summary
Watch instruction, similar to optimistic lock, when the transaction is submitted, if the value of Key has been changed by another client, for example, a list has been pushed/popped by another client, the entire transaction queue will not be executed
through the WATCH command Multiple Keys are monitored before the transaction is executed. If the value of any Key changes after 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.
3 stages
• Open: Start a transaction with MULTI • Enqueue: Enqueue
multiple commands into the transaction. These commands will not be executed immediately after receiving them, but will be placed in the transaction queue waiting to be executed.
• Execute: the transaction is triggered by the EXEC command
3 characteristics
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 command requests sent by other clients.
There is no concept of isolation level: the commands in the queue will not be actually executed until they are submitted, because any instructions will not be actually executed before the transaction is submitted, so there is no "query within the transaction to see the update in the transaction" , The query can’t be seen outside the transaction" is a 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.
Do not follow the traditional ACID AI in