redis things study notes

Redis things concept

First of all, a very important concept: Redis executes commands in a single thread, which means that all user requests will be serialized. Redis will only execute one command for the user at the same time, and the rest need to wait.

The essence of Redis transactions is a collection of commands.

The transaction supports the execution of multiple commands at once, and all commands in a transaction will be serialized.

In the transaction execution process, the commands in the execution queue will be serialized in order, and the command requests submitted by other clients will not be inserted into the transaction execution command sequence.

To sum up: Redis transaction is a one-time, sequential and exclusive execution of a series of commands in a queue.

How does Lua script guarantee atomicity?

Redis uses the same Lua interpreter to execute all commands. At the same time, Redis guarantees to execute scripts in an atomic way: when Lua scripts are executed, no other scripts and commands are executed at the same time. This semantics is similar to MULTI/EXEC. From the perspective of other clients, a Lua script is either invisible or has been executed.

However, this also means that it is not recommended to execute a slower Lua script. Since the overhead of the script is very low, it is not difficult to construct a fast-executing script. But you should note that when you are executing a slower script, no other client can execute commands.

Of course, it is not recommended to use all the commands that take too long to operate redis, such as keys *. If the amount of data is too large, redis will always look for it, causing subsequent commands to be executed, and the client may also be waiting continuously , Resulting in the system Hang live.

As shown in the figure above, all commands are queued for redis to execute.

Redis transactions have no concept of isolation level

The batch operation is put into the queue buffer before sending the EXEC command, and will not be actually executed, so there is no query within the transaction to see the update in the transaction, and the query outside the transaction cannot.

Redis does not guarantee atomicity

In Redis, a single command is executed atomically, but the transaction does not guarantee atomicity, and there is no rollback. The execution of any command in the transaction fails, and the remaining commands will still be executed.

In other words, Redis things are different from traditional relational databases (such as MySQL). MySQL can ensure that one step of a thing fails, and the rest of the data is rolled back to the state before modification, but Redis cannot. One data modification failed, and the rest are still executed normally.

Three stages of Redis transaction

1. Start business
2. Order to enqueue
3. Execute transaction

Redis transaction related commands

1. watch key1 key2 …: monitor one or more keys. If the monitored key is changed by other commands before the transaction is executed, the transaction will be interrupted (similar to optimistic lock)

2. multi: mark the beginning of a transaction block (queued)

3. exec: execute all transaction block commands (once the exec is executed, the monitoring locks added before will be cancelled)

4. discard: Cancel the transaction, discard all commands in the transaction block

5. unwatch: Cancel the monitoring of all keys by watch

Redis transaction usage example

Normal execution

Start a thing through multi, and then we store k1, k2, k3 in order,

And finally get gets the result of k1,

But after we enter these commands,

The results returned by redis are all QUEUED,

It means that it is not executed immediately, but is stored in a queue,

After we entered the exec command, redis actually executed our above commands and returned the results in order.

Cancel things

First we get the value of k1, this time it is k1,

When we open a thing and change the value of k1 to change,

Canceled things,

Finally, check again and find that the value of k1 has not changed or is k1, indicating that the transaction was successfully cancelled and not executed.

During the execution of the thing, a grammatical error occurred

First get k1, the value is also k1,

Get the value of k5 is empty nil, does not exist

Then start a thing and set k1 to change,

Then a syntax error occurred when setting k2,

Then set k5, and finally execute things,

We see that the result returned by redis is that the execution of the thing failed and the thing was cancelled.

At this time, see that the values ​​of k1 and k5 are the same as before the execution of the thing, indicating that if a syntax error occurs, the order of the whole thing will not be executed.

This kind of error is similar to a compilation error. If the java code fails to compile, it will not be executed subsequently.

During the execution of the transaction, a command execution error occurred

First get k1, the value is also k1,

Get the value of k5 is empty nil, does not exist

Then turn on a thing and auto-increment the value of k1,

But because the value of k1 is a string type, it cannot be incremented. At this time, there is no error in the command syntax and it is stored in the queue.

Then we set the value of k5 to change,

At this time, the first command of redis has a runtime error, and the self-increment fails, but the second command set k5 successfully.

At this time, the value of k1 is still k1, but the value of k5 is change.

This is similar to the runtime exception of java. After passing the syntax check, redis starts to execute the command. As long as the syntax of the command is correct, redis does not care whether the result is executed successfully, and will continue to execute the next command, so redis things and mysql If the relational database is different, if mysql fails to execute, it will roll back, but redis will not.

Use watch to monitor data

First, we set a value of k1 and money, which are k1 and 100 respectively,

Then we watch the money, and then turn on a thing,

Modify the value of k1 in things to 666, and increase money by 1 to 101,

At this time, we do not execute exec things, but open 另一个客户端and execute the command to modify money.

Then we return to the transaction command client just now, execute exec,

At this time, we can see that after executing exec, the result returned by redis is nil.

This means that when we monitor a key, in the process of executing things, if the value of this key is changed by external factors, the current thing will be cancelled, and all commands will not be executed, only when the monitored key has not been changed. , Things can be successful.

As above, if the monitoring key is not modified in the execution of the transaction, the execution of the transaction is successful.

The watch instruction is similar to an optimistic lock. When the transaction is committed, if the value of any KEY in the multiple KEYs monitored by watch has been changed by other clients, the transaction queue will not be executed when the transaction is executed using EXEC, and Nullmulti- will be returned at the same time. Bulk responds to notify the caller that the transaction has failed.