Processing after redis execution fails

When I was working in the past, I always struggled with how to deal with redis execution failure. The main thing is two problems

  1. How to deal with the program if the redis execution fails?
  2. What should I do if one or several pieces of data failed to execute in the middle of the redis transaction? Especially for redis transactions, it has been emphasized that transaction rollback is not supported when redis transactions are executed. After one of the commands in the middle fails, the subsequent commands will continue to be executed, which leads me to always have a big doubt, which will not cause data deviation ? For example, a transaction has three statements, incr key three times, if the initial value of key is 1, incr key three times, the result is 4, if one command execution fails, the result is 3, so the existing data is cheap and will cause problems It is very difficult to find, even if the problem is found, it is very troublesome to go to the actual production environment to restore the data. You can't stop the production environment first to restore the data, and then start the system.

Today, I seriously thought about these two issues, and summarized the design ideas of redis and the processing after execution failure, especially the reasons and treatment in the second case.


For question 1:

How to deal with the program if the redis execution fails?

There are two cases of redis execution failure,

  1. Network problem, command sending failed.
  2. Redis itself fails and cannot be accessed.
  3. The command or data does not meet the requirements.

For the first and second cases, once the redis connection fails, the system does not provide the automatic reconnection function. The advantage of this is that this connection fails and the command fails, which will not cause the connection to be suddenly connected and execute the following commands. The reconnection process requires procedures and operation and maintenance to ensure that it will not cause data errors.

For the third case, the command or data does not meet the requirements and cause failure. Redis's thinking is to throw this problem to the programmer, and the program should be simply and carefully checked and tested.

 


For question 2:

What should I do if one or several pieces of data failed to execute in the middle of the redis transaction? Especially for redis transactions, it has been emphasized that transaction rollback is not supported when redis transactions are executed. After one of the commands in the middle fails, the subsequent commands will continue to be executed, which leads me to always have a big doubt, which will not cause data deviation ? For example, a transaction has three statements, incr key three times, if the initial value of key is 1, incr key three times, the result is 4, if one command execution fails, the result is 3, so the existing data is cheap and will cause problems It is very difficult to find, even if the problem is found, it is very troublesome to go to the actual production environment to restore the data. You can't stop the production environment first to restore the data, and then start the system.

First, let's look at the transaction execution of redis:

The multi command starts and the exec command ends. This is a complete transaction of redis. We write the issues of the problem as sentences

set key 1
multi
incr key
incr key
incr key
exec

Let's take a look at the situation where the error occurred:

  1. An error occurs when exec has not executed successfully.
  2. The exec executed successfully, but an error still occurred.

Let’s analyze the causes of these two situations

    The first is the network or redis itself, which makes redis useless to receive the exec command. At this time, redis abandons the entire transaction and does not execute it. The reason is very simple, the transaction is useless to end, failure, there is no need to execute.

    Secondly, the exec execution succeeded, but the execution failed due to the statement syntax error, then skip this failed statement and continue to execute the next statement. Until the transaction is completed. Redis does not provide the reason for the failure rollback. First of all, the command will not be received due to other circumstances such as network reasons. All commands for a complete transaction have been received, which means that redis has clear instructions, and redis will execute according to the command. . If the command fails due to a grammatical error, it is a programmer's own code problem. Redis cannot be asked to provide more operations because of the programmer's own problems.

From this, we know the philosophy of redis very clearly. Redis guarantees the receipt of a transaction (a group of messages). As for whether the command is correct or not, it is a question that the programmer must guarantee. If the message is not received or half of the message is received, give up No execution, redis guarantees the execution speed. The programmer is sure of the correctness of all commands and data. Redis itself is only responsible for refreshing the memory it manages based on the data. This kind of design thinking is like an assembly line. The workers below are not responsible for checking whether the previous process is qualified. If he thinks it is done, he will do it.

 

===================================================================

Leave a contact: [email protected]

Public number: ghost20036 

Official QR code:

If anyone has software, technical or work problems, they can discuss them together.

Guess you like

Origin blog.csdn.net/ghossst2003/article/details/109212853