Request coalescing in Redis

Question

This might be basic question, but google didn't return satisfactory result.

If I use Redis as a cache and send tons of same requests to Redis, would it coalesce it into one request and forward only one request to server in case of a cache miss?

Answer 1

Redis is just a store: you add things to it and retrieve them back again. It has no awareness of what you are using it for (caching) or knowledge of how to forward misses to some other backend, that will depend on the application handling the request and using Redis to cache.

Answer 2

No, recuasse this is would require significant code to support it on both ends, and no server, HTTP or Redis, has built this. Each request from the HTTP server will be its own connection and will need to be responded to individually. There is no way in the current architecture of HTTP or Redis servers to receive multiple requests on one connection and reply on a different one eliminating the other request paths at the same time.

Further, given the speed of Redis, it be would rather likely that the overhead of determining which queries were identical both in request and in content would entirely negate any possible benefit of such a scheme, and probably increase the response time far more than a simple response to each would take in the aggregate. Redis would have no way of knowing that a request by client A for key foo can be ignored for client B for foo. What if one request is blocking and the other is not? What if both clients are on the same IP but entirely different processes? Again, Redis would have no way of knowing.

In your example of a cache miss, Redis would have to respond to the client somehow, and saying "I've got nothing for you" is precisely the route to go. Bearing in mind that the largest portion of overhead in talking to a Redis server is the TCP connection it should be quite obvious that since you want to keep the connection open to amortize that over multiple requests, thus you would still have to reply on the connection made in the request, and further that there is no way to know that request A on connection B can be treated the same as request Z on connection D.

This is why it would take significant rewriting of the basic communication protocol and architecture on both ends of the pipes. It also sounds very much like rather premature optimization without data to support the reasoning behind it. Redis is capable of handling over a million requests per second, it is dubious at best that all the additional complexity and computation on both sides to provide your example would improve that.