I. Overview:

Concept: Multiple commands can be executed at a time, which is essentially a collection of commands. All commands in a transaction are serialized, executed sequentially and not inserted by other commands, without any insertion.

Redis partially supports transactions, but it doesn’t: strong consistency

What it can do: Execute a series of commands in a queue at once, sequentially, and exclusively

Common commands:

  • MULTIAfter MULTI executes, the client can continue to send any number of commands to the server. These commands are not executed immediately, but are placed in a queue.
  • EXEC: Executes all commands in the queue
  • DISCARD: Clears the transaction queue and abandons the transaction
  • UNWATCHCancelled:WATCHCommand to monitor all keys
  • WATCH key1 key2 ...: Monitors a key (or keys) and interrupts a transaction if the key (or keys) is changed by another command before the transaction executes.

Two, use:

Normal execution:

To abandon a transaction:

All in company:

An instruction syntax error, note: I said syntax error! EXEC execution reported an error.

Creditor (partial support) :

Injustice has a head, debt has a master, right release, who is wrong to find who. Redis partially supports transactions, allowing for and reporting errors.

WATCH Monitor: Monitors transactions before starting them

Cached data, anyone can take it and change it, so you have to tag it to monitor behavior. Pessimistic lock/Optimistic lock /CAS(Check And Set)

  • Pessimistic Lock: Pessimistic. Every time I go to retrieve data, I think someone else will modify it, so EVERY time I try to retrieve data, I lock it, so that someone else will block it until it gets the lock. Traditional relational database inside used a lot of this locking mechanism, such as row lock, table lock, read lock, write lock, etc., are in the operation before the first lock.
  • Optimistic Lock: Just as the name implies, I am very optimistic. Every time I go to get the data, I think that others will not modify it, so I will not lock it. But when I update the data, I will judge whether others have updated the data during this period, and I can use the version number and other mechanisms. Optimistic locking is suitable for multi-read applications to improve throughput,
  • Optimistic locking policy (common) : Commit version must be greater than record current version to perform update. This does not affect the concurrency, but can meet the requirements.

Case study: Credit cards and debts

Normal condition: No plug tampering

Tampering with plugs:

After being monitored by WATCH, someone modifies balance, which will interrupt the transaction and the latest value must be updated to successfully execute the transaction, similar to the version number mechanism of optimistic lock.

Transaction phases:

1. Open: Start a transaction with MULTI

2. Queue: Multiple commands are queued into a transaction. After receiving these commands, they are not executed immediately, but placed in a transaction queue waiting for execution

3. Execute: the EXEC command triggers the transaction

Transaction three features:

Isolated operations: All commands in a transaction are serialized and executed sequentially. The transaction will not be interrupted by command requests from other clients during execution.

2. There is no concept of isolation level: none of the commands in the queue will actually be executed until the transaction is committed, because none of the commands will actually be executed before the transaction is committed, so there is no such headache problem as “in-transaction queries will see updates in the transaction, and out-of-transaction queries will not see updates”

If a command fails to execute in the same redis transaction, subsequent commands will still be executed without rollback.

Summary:

The WATCH command monitors multiple Keys prior to transaction execution. If any Key value changes after the WATCH, the EXEC command will abort the transaction and nullmulti-bulk reply will be returned to inform the caller that the transaction failed