A pit into the Redis business

A. What is it?

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

Two. Capable

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

Three. How to play

    Common commands

1: Normal execution

2: Abort the transaction

3: The whole guilt

CASE4: The creditor of Injustice Head

Case5:watch Monitoring

    (1) Pessimistic lock/Optimistic lock/cas (Check and Set)
    (2) Watch instruction, similar to optimistic lock, transaction commit, if the value of key has been changed by another client, such as a list has been push/pop by another client, the entire transaction queue will not be executed
    (3) 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 notify the caller that the transaction execution failed

  pessimistic lock (pessimistic lock), as the name implies, is very pessimistic, every time to take the data when they think others will change, so every time when the data are locked, so that others want to take this data will block until it gets the lock. Traditional relational database in the use of a lot of this locking mechanism, such as row locks, table locks, read locks, write locks, etc., are in operation before the lock

 optimistic locks (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 when someone else has to update this data, you can use the version number and other mechanisms. Optimistic locking applies to multi-read application types, which improves throughput and optimistic locking policy: The commit version must be larger than the current version of the record to perform the update

3 stages:

    1. Open: Start a transaction with multi
    2. Queue: Enqueue multiple commands into a transaction, which is not executed immediately, but is placed in the queue of transactions awaiting execution
    3. Execute: Trigger Transaction by EXEC command

3 Features:

    1. 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.
    2. There is no concept of isolation level: a command in a queue is not actually executed until it is committed, because no instructions are actually executed before the transaction commits, 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 painful
    problem. 3. No guarantee of atomicity: Redis in the same transaction if one of the commands fails, the subsequent command will still be executed without rollback