pub enum CacheDriver {
Memory,
Redis,
RedisCluster,
Memcached,
DynamoDb,
Kv,
}Expand description
Where cached values live.
The enum names every store this crate knows how to build, whether or not
the cargo feature behind it is on. That is deliberate: CACHE_DRIVER=redis
in a build without the redis-driver feature is a build mistake, and
it deserves a message saying so — not the same “unknown driver” message a
typo gets.
use rainier_cache::CacheDriver;
use rainier_support::Setting;
assert_eq!(CacheDriver::parse("redis-cluster").unwrap(), CacheDriver::RedisCluster);
assert!(CacheDriver::parse("redys").is_err());Variants§
Memory
This process only. Fast, and shares nothing between instances.
The default because it needs no server, and the right choice for
tests and single-process development. Anything cached for
correctness rather than for speed is wrong in it — a rate-limit
counter becomes N × its limit across N instances, and a lock is
not a lock.
Redis
One Redis server, or a Sentinel-fronted primary.
RedisCluster
A sharded Redis Cluster. Keys distribute across the seed nodes.
Memcached
Memcached over its text protocol.
DynamoDb
DynamoDB, with TTL doing the expiry. No server to run.
Kv
Cloudflare Workers KV — the edge key-value store.
Read-heavy and eventually consistent. A write reaches other
edges in roughly a minute, and there is no compare-and-set at all,
so it cannot hold a lock or count anything that has to be exact.
Right for a configuration blob or a feature-flag set; wrong for a
session, a rate limit or on_one_server.
See KvCache, which says the same thing at
more length and is worth reading before choosing this.
Implementations§
Source§impl CacheDriver
impl CacheDriver
Source§impl CacheDriver
impl CacheDriver
Whether this driver is shared between instances of the application.
The question a production checklist is really asking. A rate limiter, a
lock, or a cached authorisation decision needs true here; a memoised
computation does not.
Sourcepub fn can_hold_a_lock(&self) -> bool
pub fn can_hold_a_lock(&self) -> bool
Whether this driver can hold a lock.
Shared and lock-capable are different questions, and Workers KV is
the reason: it is visible to every replica on earth and has no
compare-and-set, so two callers both win the add a lock is built
from and both believe they hold it.
The check that matters is
LockManager::is_shared, which asks
the built store rather than the configured name; this answers the same
question about a driver nobody has built yet, for a boot-time
configuration check.