064606380b
* feat: refresh policy for caches For #5318 we want to have a policy that refreshes keys before they are too old. I initially tried to fold both TTL and the refresh system into a single policy but than decided that they will basically be two policies in one with a harder-to-test interface. Semantically TTL and refresh are also a bit different (but will usually be used together): - **TTL:** Prevents that a users gets data that is too old. It is some kind of "soft correctness". In some sense this is related to the "remove if" policy where some part of the system knows for sure (or with reasonable likelyhood) that a cache entry is outdated. Note that TTL's primary job is NOT to clean up memory from old keys (even though it indirectly does that). There is no reason cached entries should be removed except for correctness (TTL and remove-if) or resource pressure -- and the latter is handled by the LRU policy. - **Refresh:** While TTL is some kind of deadline, we often have good reason to refresh the key before we pull the plug, namely when an entry is used and a bit old (but not too old). The concrete mechanism to archive this is flexible. At the moment the policy is rather simple -- just start a refresh task if a key is old and we receive a GET request -- but can be extended in the future. This also adds some integration tests for TTL+refresh. There will be follow-up changes to test the interaction with LRU as well, althouh I am pretty certain that there won't be any surprises due to the excessive testing we have in place for the policy backend itself as well as all the policies. This change also does NOT integrate the refresh with the querier for the sake of keeping the changeset "small" (i.e. it is already rather large). * docs: improve Co-authored-by: Andrew Lamb <andrew@nerdnetworks.org> Co-authored-by: Andrew Lamb <andrew@nerdnetworks.org> |
||
|---|---|---|
| .. | ||
| benches | ||
| src | ||
| Cargo.toml | ||