redis study notes transaction 03-

1.redis Affairs

Actually refers to a transaction is a set of commands will be executed in serial order, the middle can not add other command is executed. It is used to address the needs of the batch.
In redis substantially as follows:
> Multi
OK
> incr Books
the QUEUED
> Exec
(Integer). 1
(Integer) 2

multiAnd execis a sign of the beginning and end of the transaction, the middle is a transaction specific content. Services available discarding discardcommand, all transactions are not executed before the exec.
redis transaction has the following characteristics:

1. all guilt

            >set books python
            ok
            >multi
            ok
            >set a1 b1
            QUEUED
            >cbaafasfaf books linux
            (error) ERR unknown command 'cbaafasfaf'
            >set a2 b2
            QUEUED
            >exec
            (error) EXECABORT Transaction discarded because of previous errors.
            >get a1
            (nil)
            >get a2
            (nil)

Visible multi statement, enter once per instruction will be tested once, when an error occurs will be returned directly to a grammar error, the exec after submission of the statement will find that the transaction will not be executed.

2. injustice head with the main debt

        >set books redis
        ok
        >multi
        ok
        >set k1 v1
        QUEUED
        >incr books
        QUEUED
        >set k2 v2
        QUEUED
        >exec
        1) OK
        2) (error) ERR value is not an integer or out of range
        3) OK
        >get k1
        "v1"
        >get k2
        "v2"
        >get books
        "redis"

Visible, redis transaction will correct instructions are executed, just stuck the wrong command. Why is this?
In fact redis transaction is not a strict transaction, as long as the middle of no apparent particularly obvious errors, they will be correct instruction is executed, only to abandon the wrong order. And redis transaction rollback does not support this operation.

2. pessimistic locking and optimistic locking

Pessimistic locking it that operate the client's data will cause confusion, in order to prevent erroneous operation of the data, the data before the operation will be to manipulate the database table that contains the data to lock a range of different, to prevent misuse.
The optimistic locking believe that the client will not affect the operation of the basic data, only some think could possibly go wrong data locked.

Specific operation is as follows:

Pessimistic lock: table and row locks or other locking mechanism using the database implementation

Optimistic locking: redis use watchthe method to achieve, which is essentially also added a lock, when the other is a request to modify the watch data, the transaction will fail to perform, which requires re-initiate the request. Note that in redis in, watch can only be used before the start of the transaction, or an error occurs.
The basic use is as follows:

import redis

def key_for(user_id):
    return 'account_{}'.format(user_id)

def bussiness(client,user_id):
    key = key_for(user_id)
    while True:
        client.watch(key)
        # 数值加倍
        value = int(client.get(key))
        value *= 2
        #用管道提交事务
        pipe = client.pipeline(translation=True)
        pipe.multi()
        pipe.set(key,value)
        #尝试提交事务，成功时跳出循环;失败时重新尝试。
        try:

            pipe.exec()
            break
        except WatchError:
            continue
        return int(client.get(key))

client = redis.StructRedis()
user_id = 'abc'
client.setnx(key_for(user_id),5) #初始化
print(bussiness(client,user_id))

Borrowing transaction pipeline multiple I / O operations can be compressed into a single I / O, to improve efficiency. Commit the transaction redis client in python to force the use of the pipeline.

Despite the pessimistic lock is safe, but have to take the lock in the implementation, operation data, the process releases the lock, and other requests in this process can only wait. Concurrent cases, especially at high concurrent requests, the speed is really slow. It generally apply only to bigger changes to the database or other important situation.

Optimistic locking applies to read operations as a main request, a case where data security requirements are not demanding, can significantly improve the processing speed in the request for high concurrency.