It seems that your Redis server’s I/O processing is based on a multi-threaded model, but this I/O multi-threaded model may lead to message ordering issues.
Suppose there is a business application that has deployed a two-node cluster service and is using your Redis service. Let’s call them socket1 and socket2.
First, socket1 sends a command: SET a=1, and then socket2 sends a command: SET a=2.
However, because your Redis server uses a multi-threaded model for I/O processing, it’s possible that Redis might finish parsing the command from socket2 (SET a=2) before parsing the command from socket1 (SET a=1).
This could lead to the scenario where the command from socket1, which was sent earlier, gets overridden by the command from socket2 that was processed later, resulting in the final value of a being 1, which is incorrect.
Comment From: sundb
@qq664042 IMHO, I don't think this is a problem. In any case, for two individual connections, even single threads, we can't guarantee that messages from two connections will arrive in the order they were sent, we can only guarantee that whoever arrives first executes first.
Comment From: qq664042
IMHO, I don't think this is a problem. In any case, for two individual connections, even single threads, we can't guarantee that messages from two connections will arrive in the order they were sent, we can only guarantee that whoever arrives first executes first.
Because of your multi-threaded parsing approach, it could also lead to the issue where commands that arrive first are parsed later, which would reproduce the problem I mentioned earlier.
Comment From: sundb
@qq664042 Whether multi-threaded or single-threaded, we can't guarantee the order of commands from multiple connections, e.g. client A sends a ping, but client B sends a very large command, even if client b arrives first, its parsing is still delayed because we need to wait for all the data to be read.