2 ms·

What's the effect of this system on consistency guarantees? Seems like clients could end up in a state where they serve stale data due to (undetectably) not rec

What's the effect of this system on consistency guarantees? Seems like clients could end up in a state where they serve stale data due to (undetectably) not receiving the push updates. It also looks like client / protocol implementations are about to get a lot more complex, even if the feature is being used by the majority of users?

antirez 7y ago
This is discussed in the blog post itself. If you want to ask a more specific question I'll be happy to reply to my best knowledge.
- ricardobeat 7y ago
  My bad for not being clear enough. I was thinking of, for example, a networking issue where both server and client are still “connected” but delivery never happens. Can be solved with tuning timeouts / client-side TTL as mentioned elsewhere, but I was wondering specifically if this would change Redis’ known guarantees for data consistency, what happens during partition etc. More of a theoretical question. On the second point, the post talks about having the feature disabled by default; I was curious regarding the protocol itself - it is currently quite simple, and by adding extra cache-control metadata it sounds like correct client implementation might become a lot more complex, but it’s hard to tell without having seen what the new protocol looks like.
  - antirez 7y ago
    Yep your concern about consistency is definitely correct, but the good thing is that the invalidation connection can be pinged continuously by the client, as often the client wants (for instance 10 times every second). As soon as the connection is timing out, the client may decide to no longer serve the cached data. Of course every time the invalidation connection is closed at all, the client should flush the cached data completely or apply a very short TTL to the set of cached data. About your second point: today I implemented even the feature (in the unstable branch) to support RESP2, that is, the current Redis protocol. But even using RESP3 the complexity is very low. On the data connection side you have just to use the CLIENT command to activate it. In the data connection, what you could receive, if you associate a callback in your client, is push data that notifies you the invalidation connection is no longer active. Push data is normally discarded by the client implementation of RESP3 if no handler is associated. On the invalidation connection, in RESP3 mode, you get again push data with a callback, or if you are in RESP2 mode, you just subscribe to the special channel __redis__:invalidate, and you get the messages about the caching slots that need to be invalidated.
naphaso 7y ago
Client cache should be bound to active connection. Strong consistency also require server to receive syncronious confirmation from each client with cache bucket before completion of operation, but it's a lot of overhead and not needed in most of the cases.
- antirez 7y ago
  Totally agree, moreover here the window of inconsistency can be tuned by pinging the invalidation connection as often as needed. However I'm sure we better have excellent documentation about best practice, like: if the invalidation connection is gone, the cache should be flushed to avoid stale reads, and things like that. Notably the reverse condition is ok: if the data connection is gone, one can reconnect and enable again redirection to the old client ID :-D
zzzcpan 7y ago
Obviously no consistency guarantees. To be fair, strong consistency models don't work for client side caching and strong eventual consistency while works, almost no one in the world implements it yet.

antirez 7y ago

This is discussed in the blog post itself. If you want to ask a more specific question I'll be happy to reply to my best knowledge.

ricardobeat 7y ago
My bad for not being clear enough. I was thinking of, for example, a networking issue where both server and client are still “connected” but delivery never happens. Can be solved with tuning timeouts / client-side TTL as mentioned elsewhere, but I was wondering specifically if this would change Redis’ known guarantees for data consistency, what happens during partition etc. More of a theoretical question. On the second point, the post talks about having the feature disabled by default; I was curious regarding the protocol itself - it is currently quite simple, and by adding extra cache-control metadata it sounds like correct client implementation might become a lot more complex, but it’s hard to tell without having seen what the new protocol looks like.
- antirez 7y ago
  Yep your concern about consistency is definitely correct, but the good thing is that the invalidation connection can be pinged continuously by the client, as often the client wants (for instance 10 times every second). As soon as the connection is timing out, the client may decide to no longer serve the cached data. Of course every time the invalidation connection is closed at all, the client should flush the cached data completely or apply a very short TTL to the set of cached data. About your second point: today I implemented even the feature (in the unstable branch) to support RESP2, that is, the current Redis protocol. But even using RESP3 the complexity is very low. On the data connection side you have just to use the CLIENT command to activate it. In the data connection, what you could receive, if you associate a callback in your client, is push data that notifies you the invalidation connection is no longer active. Push data is normally discarded by the client implementation of RESP3 if no handler is associated. On the invalidation connection, in RESP3 mode, you get again push data with a callback, or if you are in RESP2 mode, you just subscribe to the special channel __redis__:invalidate, and you get the messages about the caching slots that need to be invalidated.

naphaso 7y ago

Client cache should be bound to active connection. Strong consistency also require server to receive syncronious confirmation from each client with cache bucket before completion of operation, but it's a lot of overhead and not needed in most of the cases.

antirez 7y ago
Totally agree, moreover here the window of inconsistency can be tuned by pinging the invalidation connection as often as needed. However I'm sure we better have excellent documentation about best practice, like: if the invalidation connection is gone, the cache should be flushed to avoid stale reads, and things like that. Notably the reverse condition is ok: if the data connection is gone, one can reconnect and enable again redirection to the old client ID :-D

zzzcpan 7y ago

Obviously no consistency guarantees. To be fair, strong consistency models don't work for client side caching and strong eventual consistency while works, almost no one in the world implements it yet.