The new features of Redis 6.0 were also identified through step-by-step discussions and optimizations.
Many of these features have been introduced in previous releases such as RC.
But there are some new changes in the official GA release:
  • SSL
  • ACL: better, command support
  • RESP3
  • Client Side Caching: Redesigned
  • Threaded I/O
  • Diskless replication on replicas
  • Cluster support in Redis-benchmark and improved redis-cli cluster support
  • Disque in beta as a module of Redis: start invading the message queue realm
  • Redis Cluster Proxy
  • The RDB can be deleted immediately if it is not needed any more
  • PSYNC2: Optimized replication protocol
  • Timeout setting support is more friendly
  • Faster RDB loading, 20% ~ 30% improvement
  • STRALGO, the new string command, currently only one implementation of LCS (longest common subsequence)
Antirez mentions that this is just the biggest Redis release in history, so it is prudent to recommend more testing and evaluation in the production of the app, and promises to release 6.0.1 as soon as there are major bugs. Sure enough, version 6.0.1 was released a day later, fixing an Allocator bug that had been introduced for optimization purposes and was now temporarily removed.
I just released Redis 6.0.1\. Unfortunately there was a bug in Redis 6.0.0 introduced just a few days before the release, that only happens when using the non-default allocator (libc malloc in this case triggers it). Optimization reverted, 6.0.1 released. Sorry for the issue.

This article focuses on the Client Side Caching feature.

Smallnest /RESP3 is a Redis RESP3 protocol parsing library, you can use it to communicate with the underlying Redis, or wrap it to implement a new Version of the Redis client library or Redis Server.
A year ago, @Antirez woke up at 5:30 in his hotel after attending the Redis Conference in New York City, looking out over the beautiful Manhattan streets and pondering the future of Redis among the many people. This includes client caching.
In fact, the client-side caching feature was influenced by Ben Malec of Redis Conf 2018 and suddenly opened up the @Antirez idea. As we know, many companies use Redis as a cache system and improve the performance of data access. However, in order to further deal with hot data, many enterprises still cache part of hot data on the Client side of Redis to deal with melon eating events.
For example, in Weibo, we often encounter stars cheating, stars on and off, emergencies and so on. There are several emergencies every year. In addition to using Redis to cache to avoid direct access to the database, weibo will also add more cache layers in front of it, such as’ L1 cache ‘and so on. Use memcached as the hot data cache. How to synchronize cache and Redis data in a timely manner? Ben provided some very interesting ideas.
While standing on the streets of Manhattan, @Antirez was lost in thought. Back at his hotel, he started implementing the first version of client caching. Of course, the final Redis 6.0 implementation is quite different from this initial version, but it is clear that the evolution of the client side has seen @Antirez trade off this feature. I won’t go into this history too much in this article, because we’re more focused on what this feature will look like in the end.
Redis implements a server-side assisted client cache called ‘tracking’. The client cache command is: 
CLIENT TRACKING ON|OFF [REDIRECT client-id] [PREFIX prefix] [BCAST] [OPTIN] [OPTOUT] [NOLOOP]
Copy the code
When tracking is enabled, Redis “remembers” each key requested by the client and sends an invalidation message to the client when the key value changes. Invalidation messages can be sent to the requesting client via the RESP3 protocol, or forwarded to a different connection (support RESP2+ Pub/Sub).
Tracking clients receive notifications about keys they subscribed to by prefix when broadcasting is enabled, even if they did not request the key. It also provides’ OPTIN ‘, ‘OPTOUT’ and other modes.
Invalid message: When the data of a key is changed, redis will send an invalid message to inform the client that the cached data is invalid
  • **REDIRECT**: REDIRECT invalid messages to another client. When communicating with Redis using old RESP2 instead of RESP3, the client does not support handling invalid messages, so we can enable a Pub/Sub client to handle invalid messages. Of course, if the client supports RESP3, it can also forward the invalid message to another client. This CACE we’ll show you at the end.
  • **BCAST**: Start ‘tracking’ using broadcast mode. In this mode, the client needs to set the prefix of track keys, and the invalidation messages of these keys will be broadcast to all participating clients, regardless of whether these clients request/cache these keys. When not in broadcast mode, Redis only tracks keys requested by read-only commands and only reports a failure message once.
  • **PREFIX** : only broadcast mode is applied, registering a key PREFIX. All keys that start with this prefix are modified, and an invalid message is sent. Multiple prefixes can be registered. If the prefix is not set, broadcast mode tracks each key.
  • **OPTIN**: When broadcast mode is not active, normal ** will not **track the keys of read-only commands unless they are called after ‘CLIENT CACHING yes’.
  • **OPTOUT**: When broadcast mode is not active, normal ** tracks the keys of read-only commands unless they are called after ‘CLIENT CACHING off’.
  • **NOLOOP**: Does not send the client’s own modified key.
Let’s take a look at each option.

Test environment setup

Let’s start with the RESP3 protocol options, with the REDIRECT coming last.
Before you can try it out, you first need to install a version of Redis 6.x, currently 6.0.1. Download the source code on the official website, compilation and installation is also very simple: 
make distcleanmakemake testsudo make install
Copy the code
I’m sure a compiled binary package will be available for download soon.
Start the server, which will start a service on port 6379: 
redis-server
Copy the code

Using redis-cli access, default access to native 6379 instance:

redis-cli
Copy the code
Of course, you can use ‘-h’ to view additional parameter configurations, such as using other ports, etc. Here we use the simplest example, focusing on the characteristics of the client cache.
Sometimes in order to better observe the result of redis, we use ‘Telnet’ instead of ‘redis-cli’ as the client to connect to Redis, because redis- CLI processes the result, especially the invalid message, you may not be able to observe it.

BCAST Broadcast Mode (Client Tracking on)

Start the redis server:

Start the redis – the cli:

Of course, we use Telnet to test, which is convenient to observe the return result of Redis. Just now, redis- CLI is used to update the key value to assist the test. 3 Enable RESP3 protocol:

➜ ~ Telnet localhost 6379Trying ::1... Connected to localhost.Escape character is '^]'. Hello 3%7$6server$5redis$7version$56.0.1......Copy the code

Then try enabling Tracking and reading the value of a:

client tracking on+OKset a 1+OKget a$11
Copy the code

If a redis-cli is used as another client to update a, Telnet should be notified:

127.0.0.1:6379 > set a 2 okCopy the code

Looking at Telnet, it receives an invalid message:

>2$10invalidate*1$1a
Copy the code

Note that it takes the PUSH type (>) in RESP3.

If this uses you to update the value of A using redis-cli, Telnet will no longer receive invalid messages. Unless the Telnet client gets A again, re-tracking a’s value.

Tracking can be cancelled at any time:

client tracking off
Copy the code

Tracking Key for a specific prefix (client tracking on)

The method above will track all keys. If you only want to track specific keys, Redis currently provides a way to do this, which is prefix matching. You can track only keys with specific prefixes. It applies broadcast mode.

Set the prefix and enable tracking using the Telnet client:

hello 3....... client tracking on prefix a bcast+OKclient tracking on prefix user bcast+OKCopy the code
Tracking should receive a message when a key is changed. Tracking should receive a message when a key is changed. Tracking should receive a message when a key changes.
Then we use redis-CLI to update three keys: ‘ABC’, ‘user:32432723213’ and ‘feed:6532343243432’ : 
127.0.0.1:6379> set ABC 100ok127.0.0.1:6379 > set user:32432723213 goodok127.0.0.1:6379 > set feed:6532343243432 abcOKCopy the code
Telnet client receives invalid messages for ‘ABC’ and ‘user:32432723213’, but does not receive invalid messages for ‘feed:6532343243432’ : 
>2$10invalidate*1$3abc>2$10invalidate*1$16user:32432723213
Copy the code
You can stop client caching with ‘client Tracking off’. Tracking for individual prefixes is not currently possible. Disable tracking for all keys even if you use ‘client tracking off prefix user’. 
. } else if (! strcasecmp(c->argv[2]->ptr,"off")) { disableTracking(c); } else {......Copy the code

Choose to join

Tracking can optionally be enabled if ‘OPTIN’ is used. Tracking will only be performed in the next read-only command after you send ‘Client Caching yes’, otherwise ** other read-only commands will not have tracking**.
First, we start ‘optin’ and read the finger of A. At this time, we use redis-CLI client to change the value of A to 1000. We have not received the invalid message of ‘A’. 
client tracking on optin+OKget a$12
Copy the code
Next, you send ‘Client Caching yes’ and obtain the value of A. If you change the value of A again, you will receive an error message for A: 
client caching yes+OKget a$41000>2$10invalidate*1$1a
Copy the code
Must it be followed by ‘client caching yes’? Yes, for example sending the following command will only give ‘tracking’ b, not a: 
client caching yes+OKget b_get a$42000
Copy the code

Choose to leave

If you use ‘OPTOUT’, you can also OPTOUT of tracking. Tracking will only be disabled for the next read-only command after you send ‘Client Caching off’, otherwise all other read-only commands will be tracking**.
You can see it’s the opposite of ‘OPTIN’, you can choose according to your scene.
For example, after ‘OPTOUT’ is turned on, an expiration message is received for any key change: 
client tracking on optout+OKget a$43000>2$10invalidate*1$1a
Copy the code
If we want to exclude the ‘b’ key, we can set it only: 
client caching no+OKget b$13
Copy the code
Subsequent changes to B do not receive an expiration message from B.
** Note **: ‘OPTIN’ and ‘OPTOUT’ are for non-Bcast scenarios, which track keys only if you send them read-only. In broadcast mode, whenever Redis changes a key, it will send an invalid message for the key(or the key matching the prefix), regardless of whether you have sent a read-only command for the key.

NOLOOP

In normal Settings, invalid messages are sent to all participating clients, but if ‘NOLOOP’ is set, they are not sent to clients that update the key. 
client tracking on bcast noloop+OKset a 1+OKclient tracking off+OKclient tracking on bcast+OKset a 1+OK>2$10invalidate*1$1a
Copy the code
Note that canceling tracking simply calls’ client Tracking off ‘.

REDIRECT

Finally, let’s look at the handling of forwarded messages. This is to comply with RESP2 protocol a processing mode, forwarding the invalid message to another client.

Redis-cli client ID:

127.0.0.1:6379> Client listid=4 addr=127.0.0.1:61017 fd=8 Name = age=33103 IDLE =0 FLAGS =N DB =0 sub=0 Psub =0 multi=-1 qbuf=26 qbuf-free=32742 obl=0 oll=0 omem=0 events=r cmd=client user=defaultCopy the code

Telnet to Redis and check client ID:

client id:12
Copy the code

Telnet client enables subscription invalidation messages:

SUBSCRIBE __redis__:invalidate*3$9subscribe$20__redis__:invalidate:1
Copy the code

We can then forward the redis-CLI failure message to the Telnet client:

Client Tracking on bcast Redirect 12127.0.0.1:6379> set a 1000OKCopy the code
You can see that the Telnet client received an invalid message: 
*3$7message$20__redis__:invalidate*1$1a
Copy the code
If the destination client you are forwarding has RESP3 enabled, you do not need RESP3 Pub/Sub because RESP3 natively supports Push messages.
Redis tracking feature implementation code in :tracking. C.