redis version: v7.0.8 os version: macos 12.6

Question 1:

I saw the description about client-side-caching in redis documentation:

https://redis.io/docs/manual/client-side-caching/

"""

What to do when losing connection with the server

Similarly, if we lost the connection with the socket we use in order to get the invalidation messages, we may end with stale data. In order to avoid this problem, we need to do the following things:

  1. Make sure that if the connection is lost, the local cache is flushed.
  2. Both when using RESP2 with Pub/Sub, or RESP3, ping the invalidation channel periodically (you can send PING commands even when the connection is in Pub/Sub mode!). If the connection looks broken and we are not able to receive ping backs, after a maximum amount of time, close the connection and flush the cache.

"""

I did a test:

  1. I created 3 clients(10, 11, 12), and use RESP3:
127.0.0.1:6379> client id
(integer) 10
127.0.0.1:6379> client id
(integer) 11
127.0.0.1:6379> client id
(integer) 12
127.0.0.1:6379>
  1. run cmd
[client-10] 127.0.0.1:6379> client tracking on REDIRECT 11 OPTOUT
OK
[client-10] 127.0.0.1:6379> get mykey
(nil)
[client-10] 127.0.0.1:6379> exit
// -------------------------------------------------------------
[client-12] 127.0.0.1:6379> set mykey value
OK
[client-12] 127.0.0.1:6379>
// -------------------------------------------------------------
[client-11] 127.0.0.1:6379> get mykey
"value"
[client-11] 127.0.0.1:6379>

First, I enabled tracing using client-10 and redirected invalidation messages to client-11. I executed get mykey command, I closed the connection of client-10, client-11 is still active.

client-12 executed the set mykey value command, but client-11 did not receive the notification of the invalidation message.

According to the description of the document: Similarly, if we lost the connection with the socket we use in order to get the invalidation messages, we may end with stale data. In order to avoid this problem, we need to do the following things:

My understanding: Should I clean client-cache when client-11(not client-10) is close.

But when client-10 is closed, redis-server will not send a key invalidation message to client-11. Then should I monitor the health status of client-10 and client-11 at the same time, and delete the client cache when one of the connections fails?

Question 2

still have a question:

In the documentation of the client tracking command, I saw the following description:

https://redis.io/commands/client-tracking/

""" REDIRECT : send invalidation messages to the connection with the specified ID. The connection must exist. You can get the ID of a connection using CLIENT ID. If the connection we are redirecting to is terminated, when in RESP3 mode the connection with tracking enabled will receive tracking-redir-broken push messages in order to signal the condition. """

My test: 

[client-10] 127.0.0.1:6379> client tracking on REDIRECT 11 OPTOUT
OK
[client-10] 127.0.0.1:6379> mget k1 k2 k3 k4 k5 k6 k7 k8 k9 k10
 1) (nil)
...........
10) (nil)
// ------------------------------------------------------------------
[client-11] 127.0.0.1:6379> exit
// -----------------------------------------------------------------
[client-12] 127.0.0.1:6379> mset k1 1 k2 2 k3 3 k4 4 k5 5 k6 6 k7 7 k8 8 k9 9 k10 10
OK
127.0.0.1:6379>
// ------------------------------------------------------------------
[client-10] 127.0.0.1:6379> get k1
1) "tracking-redir-broken"
2) (integer) 11
1) "tracking-redir-broken"
2) (integer) 11
1) "tracking-redir-broken"
2) (integer) 11
1) "tracking-redir-broken"
2) (integer) 11
1) "tracking-redir-broken"
2) (integer) 11
1) "tracking-redir-broken"
2) (integer) 11
1) "tracking-redir-broken"
2) (integer) 11
1) "tracking-redir-broken"
2) (integer) 11
1) "tracking-redir-broken"
2) (integer) 11
1) "tracking-redir-broken"
2) (integer) 11
"1"
[client-10] 127.0.0.1:6379>

In the example of Question-1, if client-10 tracks 10 keys, and then client-11 closes the connection, when client-12 modifies the 10 keys, client-10 receives 10 tracking-redir-broken 11. Is this correct? If I traced 1k commands, is that going to be notified 1k times?

Comment From: monkey92t

😂😂 any news???

Comment From: ranshid

@monkey92t Sorry for taking long time getting answer.

Let me try and answer your question: 1. When you decide to split the invalidation channel and the tracking channel I agree you should flush the local cache in case any of the 2 channels is disconnected. 2. AFAIK the tracking broken massage will be generated per modified key (not all keys once a single key is modified) but only for resp3 and not in resp2.