Shulou(Shulou.com)06/03 Report--

Author: antirez

Translation: Kevin (official account: middleware)

A few weeks after the release of Redis 5, I began to implement RESP3, and after a few days of work, I was able to achieve this goal. RESP3 is a new client-server protocol that Redis will use from Redis 6. The specification on https://github.com/antirez/resp3 clearly shows how this evolution of our old protocol RESP2 can improve the Redis ecosystem. Most importantly, RESP3 is more "semantic" than RESP2. For example, it has concepts such as mappings, collections (an unordered list of elements), attributes that return data (auxiliary information can be used to enhance responses), and so on. The ultimate goal is to get the new Redis client to reduce our workload, that is, we only need to determine a fixed set of rules to convert each reply type from RESP3 to a client library programming language of a given type.

In the future of Redis, I see smarter clients that better handle connections, pipelines, and state, and are obviously so much simpler in terms of user orientation that an ideal Redis client looks like:

Result= redis.call ("GET", keyname)

Of course, most importantly, you can build a higher-level abstraction, but the lowest level should look like this, and the reply returned should not require temporary filtering on a particular command: the RESP3 return type should contain enough information to return the appropriate data type, so HGETALL will return RESP3 "mapping", LRANGE will return "array", and EXISTS will return RESP3 "Boolean".

Even if the client library is not specifically designed to handle it, the new command works as expected. In RESP2, this command might return errors such as "missing methods," but later when the command was actually implemented in the client library, the type of return changed, introducing a slight incompatibility.

However, although the new protocol is an incremental improvement on the old protocol, it will introduce incompatibility on the client library side and in the application layer. For example, because ZSCORE will now return the double type instead of the string type, the application code should be updated, or the client library can implement a compatibility option that will change the RESP3 reply back to its original RESP2 type.

The Lua script will not work properly if the new protocol is not adapted, because Lua will also see more semantic types returned by the redis.call () command, and Lua will be able to return all the new data types implemented in RESP3.

As a result, people are afraid of my decision: I will only support RESP3 when Redis 6 is released, and I will not switch the Redis 6 server to RESP2 compatibility mode, so you can either upgrade the client library and applications (or use the client library backward compatibility mode), or you will not be able to switch to Redis 6.

I have good reasons for doing this, and I want to explain why I made this decision and how to alleviate the problems of users and client library authors. Let's start with mitigation measures:

* Redis5 will be fully supported within 2 years after the release of Redis 6, all key content will be migrated to Redis5, and patch-level distributions will always be available.

* Redis 6 is expected to be released in about a year or a year and a half, but Redis 6 will switch to RESP3 in about a month, so people will use, try, and handle the unstable version of Redis, which uses the new protocol for a long time. Unlike many other software, Redis stable has a large number of temporary users, both because it is the default branch on Github and because traditionally Redis stable has never been really so unstable, so this carries a lot of previous risks.

* I'm still not 100% sure, but the Lua script engine may have a compatibility mode to return the same type as Redis 5. However, compatibility is not enabled by default, and each executed script is selected to be enabled by calling the special redis.resp2_compat () function before calling the Redis command. Therefore, regardless of its configuration, every Redis 6 server will exhibit the same behavior, just as Redis has done over the past 10 years.

These are mitigation measures, which is why I decided that Redis 6 does not support both versions:

1) it may be completely useless. If people switch from Redis 6 to RESP2 mode, they will stay in the past, waiting for Redis 7 to launch and break everything without RESP2 support. At the same time, when you use a Redis 6, depending on the way it is configured, you never know what it will reply to, and the same client library may return a hash or array for the same command.

2) for no good reason, this requires more work and more complexity (see "1"), and many commands will need to check the old agreement to see which format to reply.

3) by bundling the new features of Redis 6 with protocol changes, we provide users with good reason to switch and port their clients and applications. One day it will all be over and we can focus on new things. Otherwise, we will have some Redis 6 users who have switched to the new server to use the new features, but still use the old protocols, and will repeat the same mistake when using Redis 7.

4) if someone tells you that it's a bad thing to rewrite client libraries, I don't agree. Some changes need to be made, but now that I'm implementing the server side, I find it's not that bad, and the scary thing is that most client-side work doesn't pay at all, just because of enthusiasm and willingness to share with others. I bet we'll see many implementations of RESP3 soon.

5) RESP3 is designed so that clients can automatically detect whether it is RESP2 or RESP3 and switch, so new clients can use both Redis 6 and Redis 5 as well as previous versions.

I hope it will clarify my point and the reasons behind it, and that the mitigation measures enabled during protocol switching will convince users that this will not cause "serious" damage.

For more high-quality middleware technical information / original / translated articles / materials / practical information, please follow the official account of "Brother Middleware"!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.