Redis's Transactions

Redis support for transactions is partially supported, does not want Oracle, either succeeds or fails, and Redis can partially succeed partially fail

1 is what:

You can execute more than one command at a time, essentially a set of commands. All commands in a transaction are serialized, serially executed sequentially without being inserted by another command.

2 capable:

A queue, one-time, sequential, exclusive execution of a series of commands

3 How to Play

Redis Transaction Command

The subscript lists the commands related to Redis transactions

1. DISCARD

Cancels the transaction, discarding all commands within the transaction block.

2. EXEC

Execute commands within all transaction blocks

3. MULTI

Mark the beginning of a transaction block

4. Unwatch

Suppress watch command for all key monitoring

5. WATCH key [key ...]

Monitor one (or more) key, and if this (or these) key is changed by another command before the transaction executes, the transaction will be interrupted.

Case1: Normal execution

127.0.0.1:6379> multiok127.0.0.1:6379> set K1 v1queued127.0.0.1:6379> set K2 v2queued 127.0.0.1:6379> get k2queued127.0.0.1:6379> set K3 v3queued127.0.0.1:6379> EXEC 1)OK 2)OK 3) "v2" 4) OK

CASE2: Discarding a transaction

127.0.0.1:6379> multiok127.0.0.1:6379> set K2 v22queued127.0.0.1:6379> Set K3 v33queued127.0.0.1:6379> discardok127.0.0.1:6379> get K3

CASE3: All Guilt

127.0.0.1:6379> multiok127.0.0.1:6379> set K1 v1queued127.0.0.1:6379> set K2 v2queued 127.0.0.1:6379> Set K3 v3queued127.0.0.1:6379> for ' getset ' command 127.0.0.1:6379> set K4 v4queued127.0.0.1:6379> EXEC (Error) Execabort Transaction discarded because of previous errors.

In the middle as long as there is a failure, the entire execution fails

CASE4: The creditor of the head (which fails the execution, the other succeeds)

127.0.0.1:6379> get K1"v1" 127.0.0.1:6379> keys) "K3" 2) "K2" 3) "K1" 127.0.0.1:6379> Multiok 127.0.0.1:6379> incr k1queued127.0.0.1:6379> set K2 QUEUED127.0.0.1:6379> set K3 33 QUEUED127.0.0.1:6379> set K4 v4queued127.0.0.1:6379> EXEC1) (error) ERR value is Not a integer orout of range 2)OK 3)OK 4) OK

Case 5:watch Monitoring

Pessimistic lock/Optimistic lock/cas (Check and Set)

Let's talk about table locks and row locks.

A table lock is an operation on a row of a data table, locks the entire table, and other threads cannot manipulate any one record, with the greatest degree of consistency, but with extremely poor concurrency. A row lock is a row of data that is locked in a single operation, and other threads can manipulate the data of other rows concurrently, independently of each other.

Pessimistic lock (pessimistic lock), as the name implies, is very pessimistic, every time to take the data is considered to be modified, so every time when the data are locked, so that other people want to take this data will block until it gets the lock. The traditional relational database inside uses a lot of this locking mechanism, such as row locks, table locks, read locks, write locks, etc., are locked before doing the operation. (Not that pessimistic locks are not available, such as the ability to lock the entire table when backing up a table)

Optimistic lock (optimistic lock), as the name implies, is very optimistic, every time to take the data when they think others will not be modified, so will not be locked, but in the update will be judged in the period when others have to update this data, you can use the version number and other mechanisms. Optimistic locking is useful for multi-read application types, which can improve throughput,

Optimistic locking policy: The commit version must be greater than the current version of the record to perform the update

Once exec or unwatch is executed, the monitoring lock will be canceled.

Summary:

Watch instruction, like optimistic lock, when a transaction commits, if the value of key has been changed by another client, such as a llist has been push/pop by another client, the entire transaction queue will not be executed.

The watch command monitors multiple keys before the transaction executes, and if any key value changes after watch, the execution of the EXEC command is discarded, and the nullmulti-bulk answer is returned to inform the caller that the transaction execution failed.

　　

4 Redis Transaction 3 stage:

Open: Start a transaction with multi

Enqueue: Enqueue multiple commands into a transaction, which is not executed immediately, but is placed in the queue of transactions awaiting execution.

Execute: The transaction is triggered by the EXEC command

5 3 Features of Redis transactions

Separate quarantine operation: All commands in a transaction are serialized and executed sequentially. The transaction is not interrupted by a command request sent by another client during execution

There is no concept of isolation level: a command in a queue is not actually executed until it is committed, because any instruction before submission is not actually executed, and there is no "query within a transaction to see updates in the transaction, and queries outside the transaction cannot see" This is a very troubling question.

No guarantee of atomicity: Redis in the same transaction if one of the commands fails, the subsequent command is still executed, no rollback

Redis's Transactions