Redis [QUESTION] About the invalidation messages of redis client-side caching

Hi,

I would like to ask a question about redis client-side caching(https://redis.io/docs/manual/client-side-caching/#the-redis-implementation-of-client-side-caching). That is, when the key is updated, will the invalidation messages be definitely received by the client?

As far as I know, redis Pub/Sub is a push model, and there is no guarantee that the message sent will be received.

Does redis client-side caching also use push mode? How does it ensure that the sent message will not be lost?

Thanks~

Comment From: wp973

In addition, are the invalidation messages sent in order?

When multiple keys are updated, such as:

   set a a
   set b b
   set c c

client receives invalidation messages: a, b, c

Comment From: sundb

I would like to ask a question about redis client-side caching(redis.io/docs/manual/client-side-caching/#the-redis-implementation-of-client-side-caching). That is, when the key is updated, will the invalidation messages be definitely received by the client?

As far as I know, redis Pub/Sub is a push model, and there is no guarantee that the message sent will be received.

Does redis client-side caching also use push mode? How does it ensure that the sent message will not be lost?

Yes, redis client-side caching use push mode. Redis cannot guarantee that the invalidate message will always be delivered, subscribers may miss the message due to network reasons, you can refer to the block What to do when losing connection with the server in the doc.

In addition, are the invalidation messages sent in order?

When multiple keys are updated, such as:

shell set a a set b b set c c

client receives invalidation messages: a, b, c

They must be in order.

Comment From: wp973

Thanks for your replay! @sundb

In addition, are the invalidation messages sent in order? When multiple keys are updated, such as: shell set a a set b b set c c

client receives invalidation messages: a, b, c

They must be in order.

I have another question:

How does redis ensure the orderliness of invalidation messages?

Comment From: sundb

How does redis ensure the orderliness of invalidation messages?

Because Redis command processing is always in the main thread, it ensures that the three commands are in order, and therefore the invalidate messages are in order.

Comment From: wp973

Thanks! @sundb

Um, I have another question about the backlog of invalidation messages.

If we are using Broadcasting mode based on RESP3.(https://redis.io/docs/manual/client-side-caching/#broadcasting-mode)

Does client-side caching also have a buffer to save invalidation messages similar to Pub/Sub? Also, how to deal with the backlog of invalid messages? -v-

Comment From: sundb

@wp973 Do you mean server-side or client-side? If it's server-side, there's no backlog of pub/sub. If it's client-side, it depends on the implementation of the client library.

Comment From: wp973

@wp973 Do you mean server-side or client-side? If it's server-side, there's no backlog of pub/sub. If it's client-side, it depends on the implementation of the client library.

@sundb I mean server-side, in redis.conf

1.

2.

Comment From: zuiderkwast

This is the output buffer limit for the client, meaning how much Redis can buffer when the client isn't reading replies fast enough.

When a client is using pubsub, meaning it has called SUBSCRIBE or similar command, Redis is using the limit numbers for pubsub is instead.

You can check if a client is flagged as a pubsub client using CLIENT LIST. Each line represents a client. If you see flags=N it's a normal client and if flags=P it's pubsub client. A client using CLIENT TRACKING has flags=t.

A client using tracking does not imply that it's a pubsub client. If a client is using both pubsub and tracking, you will see flags=Pt.

Comment From: wp973

This is the output buffer limit for the client, meaning how much Redis can buffer when the client isn't reading replies fast enough.

When a client is using pubsub, meaning it has called SUBSCRIBE or similar command, Redis is using the limit numbers for pubsub is instead.

Thanks! If we are using Broadcasting mode based on RESP3.(https://redis.io/docs/manual/client-side-caching/#broadcasting-mode) Redis send the "push message" instead of Pub/Sub model, is there a similar buffer for "push messages"?

Just like:

Comment From: sundb

@wp973 There is no similar buffer for "push messages". A client using tracking is still a normal client.

Comment From: wp973

@wp973 There is no similar buffer for "push messages". A client using tracking is still a normal client.

I use broadcast mode to enable tracking

CLIENT TRACKING ON BCAST

When the server sends a lot of "push messages" and the client does not consume them in time, will the server forcefully disconnect from the client?

Comment From: sundb

When the server sends a lot of "push messages" and the client does not consume them in time, will the server forcefully disconnect from the client?

Yes.

Comment From: wp973

When the server sends a lot of "push messages" and the client does not consume them in time, will the server forcefully disconnect from the client?

Yes.

Is there any corresponding configuration in redis.conf?

Comment From: sundb

client-output-buffer-limit normal 0 0 0

Unlimited by default.

Comment From: wp973

client-output-buffer-limit normal 0 0 0

Unlimited by default.

I understand, thanks for your prompt reply! (^▽^)

Comment From: zuiderkwast

Question answered? Then this can be closed?

Comment From: wp973

Question answered? Then this can be closed?

yes😀

Comment From: wp973

@sundb @zuiderkwast

Hi,

I have another question about the backlog of invalidation messages.

When the number of invalidation messages is large, but the client's consumption speed cannot keep up, this will cause the memory usage of redis to increase continuously. In extreme cases, redis memory will not be enough.

How does redis handle this situation?

Comment From: wp973

Redis does not limit the output buffer of clients that enable tracking

Comment From: sundb

@wp973 Yes, If no limit, there are countless ways for a normal to run out of the memory of Reids.

Comment From: zuiderkwast

Interesting. I have no experience with this problem. Maybe we should change the default in Redis 8?