A high-throughput, sharded in-memory key-value cache for Go with TinyLFU admission, lock-free reads, and zero allocations.
go-mcache is a high-performance, generic in-memory key-value cache library for Go. It solves the problem of efficient data caching in concurrent applications by combining TinyLFU admission control with a sharded, lock-free architecture to maximize hit ratios and throughput while minimizing allocations.
Go developers building high-concurrency services, such as web servers, APIs, or real-time systems, that require fast, scalable in-memory caching with intelligent eviction policies.
Developers choose go-mcache for its lock-free read path, TinyLFU-based admission control, and sharded design, which together provide superior performance and hit ratios compared to simpler LRU caches, especially under skewed access patterns.
high performance in-memory cache
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.
Uses atomic operations for TinyLFU frequency tracking and sharded storage with per-shard RWMutex, enabling linear scaling with CPU cores as shown in parallel benchmarks with minimal degradation.
Implements TinyLFU with Count-Min Sketch and Bloom filter to reject low-frequency items, achieving high hit ratios (e.g., 87.4% on Zipf distribution) and preventing cache pollution from one-time keys.
Tracks entries by exact key type, eliminating hash collision ambiguity and enabling efficient O(sampleSize) random sampling for eviction, as described in the architecture section.
Supports custom cost functions and maximum cost limits, allowing memory-aware caching where large values can evict multiple smaller entries, demonstrated in the cost-based eviction example.
The TinyLFU admission policy adds significant latency to reads, with CacheGet at 446 ns/op vs. CacheHas at 17.5 ns/op, as benchmarks show, making it less ideal for pure lookup-heavy scenarios without eviction benefits.
Offers numerous options like shard count, buffer size, and custom hashers, which can be overwhelming for simple use cases and requires careful tuning to avoid suboptimal performance.
For custom comparable key types, it falls back to fmt.Sprintf for hashing, which is inefficient and necessitates providing a custom hasher for production, as admitted in the supported key types section.