Redis Data Summary (iv) transactions

Edis support for transactions is now relatively straightforward. Redis can only guarantee that commands in one client-initiated transaction can be executed consecutively, but not in the middle of the other client's commands. Since Redis is a single-threaded process for all client requests, it is easy to do so. In general, Redis will process and return processing results immediately after receiving a command from a client, but when a client issues a multi command in a connection, the connection goes into a transaction context, and the subsequent command is not executed immediately, but is first placed in a queue. When the EXEC command is received from this connection, Redis executes all the commands in the queue sequentially. The results of all commands are packaged together and returned to the client. The connection then ends the transaction context. Below you can see an example

redis> Multi
Ok
Redis> INCR A
QUEUED
Redis> INCR b
QUEUED
Redis> exec
1. (integer) 1
2. (integer) 1

From this example we can see incr A, the INCR B command is issued and not executed but is placed in the queue. After calling exec, the two commands are executed consecutively, and the result is returned after the execution of the two command.
We can call the Discard command to cancel a transaction. Then the above example

redis> Multi
Ok
Redis> INCR A
QUEUED
Redis> INCR b
QUEUED
Redis> Discard
Ok
Redis> get a
"1"
Redis> Get B
"1"

It can be found that incr a incr B has not been executed. The discard command actually clears the command queue for the transaction and exits the transaction context.
Although Redis transactions are inherently equivalent to serializing isolation levels. However, the write operation in a transaction cannot depend on the result of the read operation in the transaction because the transaction context commands are queued and not executed immediately. Look at the following example

redis> Multi
Ok
Redis> get a
QUEUED
Redis> Get B
QUEUED
Redis> exec
1. "1"
2. "1"

You've found the problem. What if we want to implement INCR operations with transactions? Can you do that?

Redis> Get a
"1"
Redis> Multi
Ok
Redis> set a 2
QUEUED
Redis> exec
1. OK
Redis> get A,
"2"

The conclusion is clear that this is not possible. This is no different from get a and then directly set a. Obviously, because get a and set a do not guarantee that two commands are executed consecutively (get operations are not in the transaction context). It is likely that there are two clients doing this at the same time. As a result, we expect to add two times a from the original 1 into 3. However, it is possible that the two client get a, which is 1, resulting in a final addition of two results is 2. Major issues we do not have any synchronization of access to shared resource a
This means that Redis does not provide any lock-in mechanism to synchronize access to a.

Fortunately, after Redis 2.1 added the Watch command, which can be used to implement optimistic locking. See an example of the correct implementation of the INCR command, just add watch a in front

Redis> Watch A
Ok
Redis> get a
"1"
Redis> Multi
Ok
Redis> set a 2
QUEUED
Redis> exec
1. OK
Redis> get A,
"2"

The watch command monitors the given key, and the entire transaction fails if the monitored key has changed since the call to watch. You can also call watch to monitor multiple keys more than once. This allows you to add optimistic locks to the specified key. Note that watch key is valid for the entire connection, and the transaction is the same. If the connection is broken, both the monitoring and the transaction are automatically purged. Of course. The Exec,discard,unwatch command clears all monitoring in the connection.

The transaction implementation of Redis is so simple that there are certainly some problems. The first problem is that Redis only guarantees that each command of a transaction executes consecutively, but if one of the commands in the transaction fails, the other commands are not rolled back, such as the type of command used does not match.

Redis> Set a 5
Ok
Redis> Lpush B 5
(integer) 1
Redis> Set C 5
Ok
Redis> Multi
Ok
Redis> INCR A
QUEUED
Redis> INCR b
QUEUED
Redis> incr C
QUEUED
Redis> exec
1. (integer) 6
2. (error) ERR operation against a key holding the wrong kind of value
3. (integer) 6

You can see that although INCR B failed, the other two commands were executed.

The last very rare problem is that if Redis is accidentally hung up during the execution of a transaction. It is a pity that only some of the commands have been executed, and the latter is discarded. Of course, if we use the Append-only file method to persist, Redis writes the entire transaction content with a single write operation. That is, it is still possible to only partially write transactions to disk. In the case of a partial write transaction, the Redis reboot detects this condition and then fails to exit. You can use the Redis-check-aof tool to repair, and repair deletes the contents of a partially written transaction. After the repair is complete, you can reboot.

Redis Data Summary (iv) transactions