Redis Tutorial 6--redis Transactions

Redis 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 127.0.0.1:6379> Multi Ok Redis 127.0.0.1:6379> incr A QUEUED Redis 127.0.0.1:6379> incr b QUEUED Redis 127.0.0.1:6379> 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 after the execution of the two commands is returned.
We can call the Discard command to cancel a transaction. Then the above example:

Redis 127.0.0.1:6379> Multi Ok Redis 127.0.0.1:6379> incr A QUEUED Redis 127.0.0.1:6379> incr b QUEUED Redis 127.0.0.1:6379> Discard Ok Redis 127.0.0.1:6379> Get a "1" Redis 127.0.0.1:6379> 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. Most likely there are two clients doing this at the same time, that is, if we want to implement a function similar to the INCR command, get a to take out my value first, then a++, then set a, we expect to add two times a from the original 1 to 3. However, it is possible that the two client get a, which is 1, resulting in a final addition of two results is 2. Main problem 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 before adding Watcha:

Redis 127.0.0.1:6379> Watch A Ok Redis 127.0.0.1:6379> Get a "1" Redis 127.0.0.1:6379> Multi Ok Redis 127.0.0.1:6379> Set a 2 QUEUED Redis 127.0.0.1:6379> exec 1. OK Redis 127.0.0.1:6379> 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 the 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 127.0.0.1:6379> Set a 5 Ok Redis 127.0.0.1:6379> Lpush B 5 (integer) 1 Redis 127.0.0.1:6379> Set C 5 Ok Redis 127.0.0.1:6379> Multi Ok Redis 127.0.0.1:6379> incr A QUEUED Redis 127.0.0.1:6379> incr b QUEUED Redis 127.0.0.1:6379> incr C QUEUED Redis 127.0.0.1:6379> 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.

Another 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.

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

Redis Tutorial 6--redis Transactions