3 ms·

As an extension, for use cases where this is not feasible (eg. you have clustering, non-trivial permission checks or multi-entity payloads etc.) it is quite con

• derefr 5y ago
  I would note that while Nginx itself doesn’t natively support Redis (and so you have to script things yourself in that case), it does have full native support for memcached (or rather, the memcached wire protocol, spoken by several backends, though sadly Redis isn’t one of those.) See http://nginx.org/en/docs/http/ngx_http_memcached_module.html http://nginx.org/en/docs/http/ngx_http_memcached_module.html for details. Basically, you can hand off to memcached as if handing off to an upstream, and then if memcached doesn’t have the key, continue on trying to resolve the response through your actual app-server upstream. (This is essentially the same thing you’re suggesting doing through scripting, to be clear; it’s just easier to implement for the memcached case.) This type of middleware-level “read-aside” caching is really neat, because it enables push-based response caching: rather than having a read-through cache that expires items out of itself, where an expired item potentially leads to a thundering herd of clients all trying to grab the expired item and so generating independent requests to your backend (that can hopefully be coalesced into a single recomputation, but that’s unlikely in a distributed environment), you can instead just keep the cache always-populated, and every once in a while — perhaps on a schedule, perhaps in response to discovering new primary-source data — recompute your denormalized/report resource, and atomically overwrite what was in the cache with the new data.