Strong Consistency via Raft
The cluster exposes the semantics of a single deterministic state machine. Once a write succeeds, every subsequent read sees the latest value.
Cache-Cat is a high-performance key-value cache built on the Raft consensus protocol β pairing cache-grade read speed with the strong consistency and high availability of a distributed database.
For small and mid-sized teams who want high availability without a truck-load of middleware. Cache-Cat unifies a key-value database, a configuration & service-discovery center, a distributed cache, and a distributed lock β in a single binary.
Redis clustering solves availability, not consistency β an acknowledged write can still be lost on failover. Cache-Cat guarantees committed data is never lost.
These consensus systems were never designed for caching. Cache-Cat adds LRU / TinyLFU eviction and max-memory limits β at roughly 500k writes/s vs TiKV's ~200k.
TiKV persists the state machine to disk. Cache-Cat keeps the state machine fully in memory for ultra-fast reads, while Raft logs guarantee durability.
Every design decision trades nothing away on the read path while guaranteeing your committed data survives any single-node failure.
The cluster exposes the semantics of a single deterministic state machine. Once a write succeeds, every subsequent read sees the latest value.
~500k writes/s. Reads use lease-based reads to return within the lease period without extra consensus.
Raft persists and replicates the operation log before acknowledging. Unlike Redis, an acked write can never be silently dropped on failover.
Data lives entirely in memory (hash maps and optimized structures). The persisted Raft log plays the role of Redis AOF β durability without read-path disk I/O.
Built on a forked moka. Evictions are driven deterministically by the leader through consensus, plus max-memory limits β true cache semantics.
A self-developed logical-clock scheme makes TTL expiration deterministic across nodes β no clock-skew inconsistencies, even across leader switchovers.
A CAS-based post-snapshot strategy avoids fork-induced STW pauses and copy-on-write memory blow-up, while supporting large values.
Speaks the RESP protocol and Redis Sentinel commands, so existing Redis clients can drive failover with minimal changes.
Transport security across the cluster, including mutual TLS β keeping inter-node and client traffic encrypted.
Stop stacking middleware. Cache-Cat covers four common roles with a single, consistent system.
Like TiKV β store critical business data that must never be lost, backed by Raft replication.
A Consul / ZooKeeper-style registry and configuration center (with client integration).
A Redis / Dragonfly / Valkey-class cache. Reads rival modern in-memory caches; writes sustain 500k+ ops/s.
Stronger guarantees than Redis-based locks (including Redlock's well-known corner cases), closer to ZooKeeper / etcd.
Cache-Cat provides strong consistency through the Raft consensus protocol. The cluster behaves as a single deterministic state machine β the moment a write succeeds, all subsequent reads observe it.
The hard problems solved so caching and consensus can coexist.
Clock skew between leader and followers would make TTLs expire at different moments, breaking RMW commands like SET NX. Cache-Cat's self-developed Clock Consensus replaces the physical clock with a write logical clock derived as max(write_logical_time, read_logical_time, physical_time) and committed with each entry.
Expiration of the core cache map depends on this logical clock instead of any node's local time, so every node expires keys deterministically. Read requests generate a monotonically increasing read logical timestamp in memory β no extra consensus needed β and bounded clock offset (election time > clock offset) keeps it monotonic across leader switchovers.
Redis-style fork causes copy-on-write memory blow-up and brief STW pauses. Cache-Cat instead treats each value as an atomic unit and converts writes during a snapshot into CAS operations with per-value version numbers (a ZooKeeper-inspired, post-snapshot approach).
The snapshot thread iterates and streams data to disk while business threads keep serving. Recovery restores the full snapshot, then replays the versioned CAS queue. The logical clock is carried through the queue so expiration stays deterministic after recovery.
Both LRU and TinyLFU evictions are initiated by the leader through consensus to keep data iteration deterministic. Cache-Cat forked moka to read the tail of the LRU/LFU queues β the least-used data β and proposes its deletion.
Because reads run concurrently with consensus for performance, an entry being evicted may briefly still be readable, but it is ultimately deleted. Scheduled deletion is backed by a flurry-based concurrent map.
Cache-Cat maps Redis-style types onto Rust structures: String via moka, Hash/Set via concurrent maps (flurry), List via linked lists / crossbeam SegQueue, and Sorted Set via BTreeSet.
Single-key ops are atomic under moka. A read/write-lock scheme is acquired only for the rare multi-key operations, so the common single-key path stays lock-light and fast.
Rather than proxies or Kubernetes operators, Cache-Cat implements Redis Sentinel-compatible commands directly on the default Redis port β every node answers sentinel queries, so standard clients handle failover.
Replica nodes reject reads by design: under the RESP protocol there's no per-request consistency flag (as etcd has), so allowing replica reads could return stale data after a failover.
TiKV persists its state machine to disk for durable storage. Cache-Cat keeps the state machine entirely in memory for ultra-fast reads, relying on replicated Raft logs for durability and strong consistency.
Yes. Neither Redis Cluster nor Sentinel uses a consensus protocol. The primary replies to the client before replicating; if it crashes before replication completes and a replica is promoted, the acknowledged write is permanently lost. Split-brain is also possible.
Raft only requires the operation log to be persisted and replicated β not the state machine. The data structures stay in memory (like Redis AOF for the log). Reads need no extra disk access; only writes pay a small latency cost, in exchange for never losing committed data.
The RESP protocol has no per-request consistency flag (unlike etcd). Allowing replica reads could return stale data after a failover, so replicas reject reads to preserve strong consistency.
Around 500k writes/s (vs ~200k for TiKV under similar conditions), and 500k+ ops/s sustained. Most production workloads are ~95:5 read:write, and reads return within the lease period β so write latency rarely dominates.
Cache-Cat is open source under the Apache License 2.0.
Star it on GitHub β