Help Center/ Distributed Cache Service/ FAQs/ Instance Types/Versions/ New Features of DCS for Redis 6.0
Updated on 2024-06-19 GMT+08:00

New Features of DCS for Redis 6.0

DCS for Redis 6.0 is compatible with the new features of the open-source Redis 6.0, in addition to all the improvements and commands in Redis 5.0.

RESP3

Redis 6.0 introduced RESP3, the next-generation Redis protocol which implements more data types than RESP2.

  • Null: a non-existent value. It replaces RESP2's *-1 and $-1.
  • Array: an ordered collection
  • Simple string: a space-efficient non-binary safe string
  • Blob string: a binary safe string
  • Simple error: a space-efficient non-binary safe error code or message
  • Blob error: binary safe error code or message
  • Boolean: true or false
  • Number: a 64-bit signed integer
  • Big number: a large number
  • Double: a floating point number
  • Verbatim string: a binary safe string with a text format
  • Map: an unordered collection of key-value pairs
  • Set: an unordered collection of non-repeated elements
  • Attribute: attribute key-value pairs, similar to Map
  • Push: out-of-band data, similar to Array, used by the Redis server to push data to the client.
  • Hello: response returned by the HELLO command, sent when the connection between the client and the server is established.

To use RESP3, ensure that the client SDK supports it. Otherwise, the client SDK communicates with the server through HELLO of RESP2.

Client-side Caching

Redis 6.0 uses tracking to proactively instruct clients to refresh their cache. There are three implementation modes:

RESP3
  • Default mode
  • Broadcasting mode
RESP2
  • Redirecting mode

Format for enabling client-side cache tracking:

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

In RESP3, the server uses Push messages to send notifications. In the default mode, Redis remembers the keys requested by each client. When the value of a key changes, Redis sends an invalidation message to notify the corresponding client. Note that Redis notifies each client only once. If the value changes again later, the client must read the key again to enable tracking. To enable tracking in the default mode, use the following command:

CLIENT TRACKING ON 

In the broadcasting mode, all clients are notified when the value of the key matching a tracked key prefix changes. If there is large number of keys that match the key prefix or there is large number of changes, the server sends many invalidation messages, consuming much network bandwidth. To enable tracking in the broadcasting mode, use the following command:

CLIENT TRACKING ON BCAST PREFIX key-prefix

If the client SDK does not support RESP3, only the redirecting mode of RESP2 can be used to implement tracking. In this case, a dedicated client that supports RESP3 needs to act as the transit node that redirects invalidation messages from Redis to specific subscription channels.

Figure 1 Client cache tracking (redirecting mode)

Faster RDB Loading

In Redis 6.0, the loading of RDB files is optimized for a 20% to 30% increase in speed.

Optimized INFO Command

The processing of the INFO command is optimized, especially in the scenario where a large number of clients are connected, resulting in higher performance and lower latency.