Redis transactions (partially supported)

Holiday over, hurry to update the east, the recent project has been on the line stage, daily overtime debugging optimization module function, resulting in a few days back home is already midnight. Okay, here we are.

some small summaries of Redis transactions

    When it comes to business, it certainly comes to the idea that, like a traditional relational database, either all succeeds or all fails. The four characteristics of business are acid. But it's not right here. Redis transactions may not be the same as a relational database because it is only a partial support transaction, which is explained in detail below.
    is what. You can execute more than one command at a time, essentially a set of commands. All the commands in a transaction are serialized, serially executed sequentially without being inserted by other transactions, and not allowed to do so
    . A queue, one-time, sequential, exclusive execution of a series of commands
    how to play. Open transaction using multi, but not necessarily open, Redis will return OK on behalf of me received, all commands using the EXEC call, using discard to discard the transaction, indicating no play

The commonly used commands are:
Watch key monitors one or more keys, and if this or these keys are changed by other commands before the transaction is executed, the transaction is interrupted
MULTI marks the beginning of a transaction block
EXEC executes commands within all the transaction blocks
DISCARD Cancel the transaction and discard all commands within the transaction block
Unwatch Suppress Watch command for all key monitoring
1: Normal execution MULTI ... Exec
2: Discard Transaction DISCARD
3: All guilt either all succeed, or all fail, command error
4: Wronged head creditor command correct, but execution failure error
5:watch monitoring: Pessimistic lock/optimistic lock/cas (check and set)
Pessimistic Lock: Lock the whole table, performance is very poor, but the consistency is very high
Optimistic lock: In order to guarantee high concurrency, but also guarantee not to say the entire table, after each record plus a version number without a tamper, the first monitoring in the open multi, to ensure that the two amount of change in the same transaction has the block tamper, horizontal knife win love, first watch key modified value others changed That's a failure. If I knew someone else had changed, I'd first unwatch at watch in multi and then modify the Exec commit execution

Three stages:
1. On: Start a transaction with Multi
2. Queue: Queue multiple commands into a transaction, and find these commands are not executed immediately, but put into wait for the execution of the transaction queued
3. Execute: Trigger Transaction by EXEC command
three attributes: Individual Quarantine operation: All commands for a transaction are serialized, sequentially implementing the concept of
No isolation level: No instruction is actually executed before a transaction commits
does not guarantee atomicity: Redis in the same transaction, if one command fails, the subsequent command will still be executed without rolling back the