Redis: How do I communicate with the client?

[[406813]]

There is a saying in the martial arts world that all martial arts are indestructible except speed. This saying is tailor-made for me.

I am a Redis service, and what I am most proud of is my speed. My QPS can reach 100,000.

I have countless younger brothers under me. They come to me from time to time to store or take away some data. I call them clients and give them the English name Redis-client.

Sometimes one younger brother will come very frequently, and sometimes a bunch of younger brothers will come at the same time, but even if there are many younger brothers, I can manage them in an orderly manner.

One day, my brothers asked me.

Back then, in order to prevent my younger brothers from slowing down my impressive speed, I racked my brains when designing their communication protocol and formulated the following three principles:

• Simple implementation
• Fast parsing speed for computers
• Highly readable for humans

Why is it designed like this? Let's first look at the process of issuing an instruction. First, the instruction operation needs to be encapsulated on the client, transmitted using the network, and finally parsed and executed on the server.

If this process is designed into a very complex protocol, then the encapsulation, parsing, and transmission process will be very time-consuming, which will undoubtedly reduce my speed. What, you ask me why I should follow the last rule? It is a gift to programmers. I am really too kind.

I call the protocol I created RESP (REdis Serialization Protocol), which works on top of the TCP protocol as a standard form of communication between me and the client.

Having said that, I can't wait to show you the masterpiece I designed, but I am a big brother after all, so I have to put on some airs and I can't take the initiative to show it to you.

So I suggest you use the client to send a command to the server directly, and then take out the message corresponding to this command to have a visual look. Having said that, I have been encapsulated very tightly, and under normal circumstances you cannot see the specific messages of my internal communication, so you can pretend to be a Redis server to intercept the messages sent to me by my brothers.

The implementation is also very simple. My brother and I communicate based on Socket, so we start a ServerSocket locally to listen to port 6379 of the Redis service:

 public   static void server() throws IOException {
    ServerSocket serverSocket = new ServerSocket(6379);
    Socket socket = serverSocket.accept();
    byte[] bytes = new byte[1024];
    InputStream input = socket.getInputStream();
    while(input. read (bytes)!=0){
        System. out .println(new String(bytes));
 }
 }

Then start the redis-cli client and send a command:

 set key1 value1

At this point, the disguised server will receive the message and print it on the console:

 *3
 $3
 set  
 $4
 key1
 $6
 value1

Seeing this, we can vaguely see the keywords we just entered, but there are also some other characters. How to explain them? It’s time for me to reveal the format in the protocol message.

I told the younger brothers that you have to follow the rules when talking to the elder brother. So, when you make a request, you should follow the following rules:

 *<number of parameters> CRLF
 $<byte length of parameter 1> CRLF
 <Parameter 1 data> CRLF
 $<byte length of parameter 2> CRLF
 <Parameter 2 data> CRLF
 ...
 $<byte length of parameter N> CRLF
 <Parameter N data> CRLF

First, let me explain the CRLF at the end of each line. Converted into programming language, it is \r\n, which means carriage return plus line feed. Seeing this, you can understand why the commands printed out by the console are arranged vertically.

During command parsing, set, key1, and value1 are considered to be three parameters, so the number of parameters is 3, corresponding to *3 in the first line.

The first parameter set, with a length of 3, corresponds to $3; the second parameter key1, with a length of 4, corresponds to $4; the third parameter value1, with a length of 6, corresponds to $6. The line below each parameter length corresponds to the actual parameter data.

Seeing this, is it easy to understand the process of converting an instruction into a protocol message?

After the younger brother sends me a request, as the elder brother, I have to reply to the younger brother's request with instructions, and I have to classify the replies according to the content, otherwise the younger brother will not understand my instructions.

Simple String

A simple string reply consists of only one line of reply, which starts with +, does not allow line breaks, and ends with \r\n. Many commands will only reply with an OK after successful execution. This format is used to effectively minimize the transmission and parsing overhead.

Error Response

In the RESP protocol, error replies can be considered as variants of simple string replies. Their formats are very similar, with the only difference being that the first character starts with -. The content of the error reply is usually a string containing the error type and a description of the error.

Error replies occur in some abnormal scenarios, such as when an incorrect instruction is sent or the number of operands is incorrect. When the client receives the error reply, it distinguishes it from a simple string reply and regards it as an abnormality.

Integer reply

Integer responses are also widely used. They start with : and end with \r\n, and are used to return an integer. For example, when incr is executed to return the incremented value, llen is executed to return the length of an array, or the 0 or 1 returned by the exists command is used as the basis for determining whether a key exists. These all use integer responses.

Batch Reply

Batch reply is a multi-line string reply. It starts with $, followed by the length of bytes to be sent, then \r\n, then the actual data, and finally ends with \r\n. If the data to be replied does not exist, the reply length is -1.

Multiple batch replies

When the server wants to return multiple values, such as a collection of elements, multiple batch replies are used. They start with *, followed by the number of elements to return, and then followed by multiple batch replies as described above.

At this point, the communication protocol between me and my little brother has been introduced. Just now you tried to pretend to be a server, now let's try to write a client to interact directly with me.

 private static void client() throws IOException {
 String CRLF = "\r\n" ; 
 
    Socket socket=new Socket( "localhost" , 6379);
    try (OutputStream out = socket.getOutputStream()) {
        StringBuffer sb=new StringBuffer();
        sb.append( "*3" ).append(CRLF)
                .append( "$3" ).append(CRLF).append( "set" ).append(CRLF)
                .append( "$4" ).append(CRLF).append( "key1" ).append(CRLF)
                .append( "$6" ).append(CRLF).append( "value1" ).append(CRLF);
 out .write(sb.toString().getBytes());
 out .flush(); 
 
        try (InputStream inputStream = socket.getInputStream()) {
            byte[] buff = new byte[1024];
 int len ​​= inputStream.read ( buff);
 if (len > 0) {
                String ret = new String(buff, 0, len);
                System. out .println( "Recv:" + ret);
 }
 }
 }
 }

Running the above code, the console outputs:

 Recv:+OK

The above simulates the process of the client issuing a set command and receiving a reply. Similarly, you can also encapsulate other commands to implement your own Redis client and communicate with me as a younger brother.

But remember, call me big brother.