Stale cache handling with a persistent object cache

admin管理员组

文章数量:1122795

Lets say you are doing an update_option() and because of some temporary network glitches updating the value in Redis/Memcached fails and you end up with a stale cache for a specific option key. The core APIs does not seem to care about the response from wp_cache_set() and they move forward with the rest of the process. Then the subsequent updates could delete or revert that option value in DB and that could have major consequences for the app depending on what that option value is used for. How do you handle this? How is this handled in large-scale WP setups? Anything that can be improved in core?

Lets say you are doing an update_option() and because of some temporary network glitches updating the value in Redis/Memcached fails and you end up with a stale cache for a specific option key. The core APIs does not seem to care about the response from wp_cache_set() and they move forward with the rest of the process. Then the subsequent updates could delete or revert that option value in DB and that could have major consequences for the app depending on what that option value is used for. How do you handle this? How is this handled in large-scale WP setups? Anything that can be improved in core?

• cache

Share Improve this question edited Oct 7, 2020 at 16:26 fuxia♦ 107k3838 gold badges255255 silver badges459459 bronze badges asked Oct 6, 2020 at 20:02 ParhamParham 93388 silver badges1818 bronze badges 2

• Do you have a Dropin for Redis/Memcached active, that replace the core cache handling? – bueltge Commented Oct 13, 2020 at 9:23
• @bueltge Yes, I do. I am using a variation of this Memcached dropin right now and soon migrating to Redis using Object Cache Pro. But my understanding is that it doesn't matter what implementation and backend we are using since the issue is that the responses from wp_cache_set() is not handled by WP core. – Parham Commented Oct 13, 2020 at 16:47

Add a comment  | 

1 Answer 1

Sorted by: Reset to default 2 +50

The object cache is not reliable, in any case.

For example, Memcached has its own system to purge items in cache: if it "thinks" that is too full it start purging items in way that is just not predictable.

It is (or should be) known that when you have an external object cache system in place, calling wp_cache_set provides zero warranty that the cache is set. And surely wp_cache_get provides zero warranty the cache is get.

This is why core does not care about what wp_cache_get / wp_cache_set do, and to be honest, there's no way they can do that: WP allows complete override of cache functions, so core has completely no clue what those functions actually do, because those functions are literally re-written by 3rd party.

On the other hand, popular cache systems are designed to be very fault tolerant, and large-scale WP setups use redudant cache servers: when, let's say, four cache servers are connected to an application, the odds that update fails in all them are scarce. On top of that, such large-scale WP setups have monitoring in place to check health status of cache servers.

That said, the possibility of issues is never zero. This is why, for example, no hosting provider says "uptime 100% guaranteed".

Even if you remove the cache variable, a glitch might happen also in DB connection, and again, only redundance and monitoring can mitigate that.

In conclusion, yes, cache can be problematic, but no, WP core can't really do anything about that. Redundance and monitoring helps in lowering the possibility of issues to an acceptable level that, in any case, is never zero.

本文标签： Stale cache handling with a persistent object cache