Redis Study Notes

Redis's support for transactions is still relatively simple. Redis can only ensure that the commands in the transaction initiated by one client can be executed continuously without inserting commands from other clients. Redis processes all client requests in a single thread, so it is easy to do so. Generally, redis immediately processes and returns the processing result after receiving a command from a client. However, when a client sends a multi command in a connection, the connection enters a transaction context. Subsequent commands of the connection are not executed immediately, but are first put into a queue. After the exec command is received from this connection, redis will execute all the commands in the queue in sequence. Package the running results of all commands and return them to the client. Then the connection ends the transaction context. The following is an example.
Redis> multi
OK
Redis> incr
Queued
Redis> incr B
Queued
Redis> Exec
1. (integer) 1
2. (integer) 1

In this example, we can see that the incr A and incr B commands are not executed but are put into the queue. After exec is called, the two commands are executed consecutively, and the result after the two commands are executed is returned.
We can call the Discard command to cancel a transaction. Next, the example above
Redis> multi
OK
Redis> incr
Queued
Redis> incr B
Queued
Redis> discard
OK
Redis> Get
"1"
Redis> get B
"1"

We can find that incr A incr B was not executed this time. The Discard command is used to clear the transaction command queue and exit the transaction context.

Although redis transactions are essentially at the serialization isolation level. However, because the commands in the transaction context are only queued and not executed immediately, the write operations in the transaction cannot depend on the read operation results in the transaction. See the following example.

Redis> multi
OK
Redis> Get
Queued
Redis> get B
Queued
Redis> Exec
1. "1"
2. "1"

Find the problem. What if we want to implement incr operations with transactions? Can this be done?
Redis> Get
"1"
Redis> multi
OK
Redis> set a 2
Queued
Redis> Exec
1. OK
Redis> Get,
"2"

Obviously, this is not the case. This is no different from getting a and then directly set. Obviously, the get a and set a commands cannot be executed consecutively (the get operation is not in the transaction context ). Two clients may perform this operation at the same time. In the result, we expect to add a twice from the original 1 to 3. However, it is very likely that the get a values of the two clients are both 1, and the final result is 2. The main problem is that we have not synchronized access to shared resource.
In other words, redis does not provide any locking mechanism to synchronize access to.

Fortunately, the watch command is added after redis 2.1, which can be used to implement optimistic locks. Let's take a look at an example of implementing the incr command correctly. We just added watch a to the front.
Redis> watch
OK
Redis> Get
"1"
Redis> multi
OK
Redis> set a 2
Queued
Redis> Exec
1. OK
Redis> Get,
"2"

The watch command monitors the given key. When exec, if the monitored key changes from the watch call, the entire transaction will fail. You can also call Watch to monitor multiple keys multiple times. In this case, you can apply an optimistic lock to the specified key. Note that the key of watch is valid for the entire connection, and the transaction is the same. If the connection is disconnected, monitoring and transactions are cleared automatically. Of course, the exec, discard, and unwatch commands will clear all monitoring information in the connection.

Redis transaction implementation is so simple, of course there will be some problems. The first problem is that redis can only ensure the continuous execution of each command of the transaction. However, if a command in the transaction fails, other commands are not rolled back. For example, the command type 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
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

We can see that although incr B fails, the other two commands are still executed.

The last very rare problem is when redis unexpectedly crashes during transaction execution. Unfortunately, only some commands are executed, and the subsequent commands are discarded. Of course, if we use the append-only file method for persistence, redis will write the entire transaction content with a single write operation. In this way, it is possible that only some transactions are written to the disk. In the case of partial write transactions, this situation is detected when redis is restarted, and then fails to exit. You can use the redis-check-Aof tool to fix and delete some written transaction content. After the repair, the system can be restarted.