Redis 6.0 New Features: In-depth analysis of the principle and performance of client side caching

The code is old and wet. Last time you explained the Redis multi-threaded model . This time I want to know about the client side caching technology. His English name is Redis server-assisted client side caching . Can you talk about it?
I am not a prostitute. After reading it, I will like it, watch it again, and share it.

Don't pretend to be compelling, you still correct English, why don't you go to heaven, you have to talk and count, or you will pee your pants in the middle of the night. Before saying this, Ma Ge first sends a message to readers as the opening chapter.

Opening message

Don't be stingy with your compliments. If others do well, give them positive feedback. This is also a kind of altruism.

In addition, pay less attention to things that vote with "praise", and pay more attention to things that vote with "transactions".

To judge whether a person is awesome is not how many people praise him online, but how many people are willing to trade, appreciate, pay, and place orders with him.

Because praise is too cheap, and willing to have a deal with him is true trust.

Why client-side caching is needed

The implementation code of Redis of Tracking Feature https://github.com/antirez/redis/blob/unstable/src/tracking.c .

Many companies use Redis as a caching system, and have improved the performance of data access. In order to further cope with hot data, some hot data will be cached on the Client side of Redis to deal with the "meat eating incident".

For example, " this damn 996 blessing ", "Wu Yifan's generous prison cell", "Master of Time Management", " Sicong licked me and I can't me 16188e01b180c7", "Wu Xiubo is in love, can you go to jail? kind"……

In addition to using the Redis cache to avoid direct access to the database, more cache layers will be added, such as using Memcachced as a local cache for hot data:

1. First go to Memcachced to query the data, and the hit will be returned directly.
2. Memcachced misses, then query from Redis again, if hit, return the data, and save this data Memcachced
3. Redis misses, go to MySQL to query, and set to Redis and Memcachced in turn.

accessing local memory must be faster than accessing Redis through the network, so this mode can greatly reduce the delay of obtaining data, and can reduce the load of Redis and improve the performance of .

1. Access Redis to get data, and the server responds.

2. Using client-side caching, the application stores the hot data obtained in the application without having to access Redis through the network again.

   

What should be cached

• We should not cache constantly changing keys.
• We should not cache keys that are rarely requested.
• We want to cache keys that are frequently requested and change at a reasonable rate. For examples where there is no steady rate of change, such as INCR , it should not be cached.

Principles of client-side caching

The code is old and wet, and the data in Redis is modified or invalid. How to synchronize and notify the client of the invalidation in time? It's too complicated to implement it yourself.

Redis implements a server-assisted client-side cache called tracking . The command cached by the client is:

CLIENT TRACKING ON|OFF [REDIRECT client-id] [PREFIX prefix] [BCAST] [OPTIN] [OPTOUT] [NOLOOP]

Redis 6.0 implements the Tracking function and provides two modes to solve this problem. They are the normal mode and the broadcast mode using the RESP3 protocol version, and the forwarding mode

*

Normal mode

When tracking turned on, Redis will "remember" the key requested by each client. When key is found to change, it will send invalidation information to the client ( invalidation message ).

The invalidation information can be RESP3 protocol, or forwarded to a different connection (support RESP2 + Pub/Sub ).

• The server side stores the key accessed by the client and the client ID list information corresponding to the key in a globally unique table (TrackingTable). When the table is full, the oldest record will be removed and the client will be notified that the record has expired. end.
• Each Redis client has a unique digital ID. TrackingTable stores each client ID. When the connection is disconnected, the record corresponding to the ID is cleared.
• TrackingTable does not consider which database it is. Although the key of db1 is accessed, the client will receive an expiration prompt when the key of the same name in db2 is modified, but this will reduce the complexity of the system and the table The amount of stored data.

The code is old and wet, can you talk about the principle of this TrackingTable?

The Redis server uses TrackingTable store client data in normal mode, and its data type is radix tree.

The radix tree is a multi-fork search tree for sparse long integer data search, which can quickly and save space for complete mapping.

Redis uses it to store the mapping relationship between the pointer key and the client ID because the pointer of the key object is the memory address, which is the long integer data . The related operation of the client-side cache is to add, delete, modify and check the data:

Note

server will only report the invalidate message once for the recorded key. That is to say, after the server sends an invalidate message to the client, if the key is modified again, the server will not send it to the client again. Send an invalidate message.

Only the next time the client executes the read-only command again and is , the next message notification 16188e01b18565 will be sent.

The client does not open track mode by default, we need to execute the open command before getting the execution command:

CLIENT TRACKING ON|OFF
+OK
GET user:211
$3
公众号:码哥字节

Broadcast mode (BCAST)

When broadcasting mode (broadcasting) is turned on, the server will not remember which keys a given client has accessed, so this mode does not consume any memory at all on the server side.

In this mode, the server will broadcast all key failures to the client. If the key is frequently modified, the server will send a large number of invalid broadcast messages, which will consume a lot of network bandwidth resources.

Therefore, in actual applications, we set the client to register to track only the key with the specified prefix. When the key prefix matching for registration tracking is modified, the server will broadcast the invalidation message to all the clients that pay attention to the key prefix.

client tracking on bcast prefix user

This broadcast mode of monitoring keys with prefixes matches our key naming convention very closely. In actual application, we will set the same business name prefix for the keys under the same business, so we can use the broadcast mode very conveniently.

Broadcast mode is similar to normal mode. Redis uses PrefixTable store client data in broadcast mode. It stores the mapping relationship between prefix string pointer and (key and client ID that need to be notified)

Forwarding mode

Normal mode and broadcast mode require the client to use the RESP 3 protocol, which is a newly enabled protocol in Redis 6.0.

For clients using the RESP 2 protocol, implementing client caching requires another mode: redirection.

RESP 2 cannot directly PUSH the invalidation message, so another client supporting the RESP 3 protocol is required to tell the server to notify the RESP 2 client of the invalidation message through Pus/Sub.

In the redirect mode, the client who wants to be notified of the invalidation message needs to execute the subscribe command SUBSCRIBE to specifically subscribe to the channel _redis_:invalidate used to send the invalidation message.

At the same time, use another client to execute the CLIENT TRACKING command to set the server to forward the invalidation message to the client using the RESP 2 protocol.

Suppose that client B wants to get the invalidation message, but client B only supports RESP 2 protocol, and client A supports RESP 3 protocol. We can execute SUBSCRIBE and CLIENT TRACKING on clients B and A respectively, as shown below:

//客户端B执行，客户端 B 的 ID 号是 606
SUBSCRIBE _redis_:invalidate

//客户端 A 执行
CLIENT TRACKING ON BCAST REDIRECT 606

Client B can get the invalidation message _redis_:invalidate

Hot Recommendation

Redis New Features: Interpretation of the Multithreaded Model

Redis Actual Combat: Realize nearby people meet goddess through Geo type

Redis Face Master: Insight into the core principles of high-frequency issues