Redis - on request caching flow - php

Question

I've been searching around the web without success to find the answer, how exactly does the "FLOW" of the application work if you cache on user request.
For example, the most used implementation to handle "on request" caching is the follow:
pseudocode:
if(redis->hasKey('content')) {
return content;
}
else {
get_content_from_database();
cache_content_in_redis();
content_expire(10);
return content;
}
Let's say, there are suddenly 1000 requests on a certain page which uses the logic above.
Logically the first request to hit the if statement, will see there is no content under the certain key and will trigger the "else" part and retrieve the content and cache it.
My questions:
What happens with other requests?
Does the second request in line already see that there is content under the key and retrieve it?
What happens if the write of the content to redis is still in progress from the request which triggered it?
If the second request also executes the "else" part of the statement, will there find a second write in place?
Or will the write get skipped and the content from the databse will be returned until the write is complete?
Who gets the cached content?

Answer 1

To answer your question (without going into discussion if this problem shouldn't be solved differently): you could use locks (either a distributed one if your app is on multiple nodes or PHP's semaphores if your app runs on a single node).
Please note that this is a pseudo-code not an actual PHP implementation:
$contentProvider->getData('my_key');
class ContentProvider
{
private $lockHandler;
public function getData($key)
{
$this->lockHandler->acquire($key);
// Do the if/else part
$this->lockHandler->release($key);
return $data;
}
}
You basically need to block for the whole if/else part. Lets say you have 1000 requests. Then 1 request will acquire the lock and the rest (999) will wait for the one to generate the content and store it in cache. After that the remaining 999 request will follow.
The problem is that now you have 1000 request accessing the cached content sequentially. There is no parallelism anymore because every call to getData will block.
It might not be a big deal if you are running on a single node using semaphores but the moment you need to switch to a distributed locks this can affect your performance dramatically (because all calls to getData run sequentially anyway - even though they are on different nodes).
Having said that I wanted to point out one thing. The above solution will guarantee that cache is only generated once and it may seem to be a viable solution. But in reality it is not. The whole point of having cache is to be fast and able to handle requests concurrently. With locks it is simply impossible.
So if running into such situation is very probable than caching on request is simply not an option and you need to find another solution. However, if this is very unlikely to happen - just stay with the original code (without locks). Even if you generate the same data multiple times every now and then - it is probably not going to be an issue.