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.
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 →