Please check the build logs for more information.
See Builds for ideas on how to fix a failed build, or Metadata for how to configure docs.rs builds.
If you believe this is docs.rs' fault, open an issue.
Oxcache is a high-performance, production-grade two-level caching library for Rust, providing L1 (Moka in-memory cache) + L2 (Redis distributed cache) architecture.
✨ Key Features
- 🚀 Extreme Performance: L1 nanosecond response (P99 < 100ns), L1 millisecond response (P99 < 5ms)
- 🎯 Zero-Code Changes: Enable caching with a single
#[cached]macro - 🔄 Auto Recovery: Automatic degradation on Redis failure, WAL replay on recovery
- 🌐 Multi-Instance Sync: Pub/Sub + version-based invalidation synchronization
- ⚡ Batch Optimization: Intelligent batch writes for significantly improved throughput
- 🛡️ Production Grade: Complete observability, health checks, chaos testing verified
📦 Quick Start
1. Add Dependency
Add oxcache to your Cargo.toml:
[]
= "0.2.0"
Note:
tokioandserdeare already included by default. If you need minimal dependencies, you can useoxcache = { version = "0.2.0", default-features = false }and add them manually.
Features: To use
#[cached]macro, enablemacrosfeature:oxcache = { version = "0.2.0", features = ["macros"] }
Feature Tiers
# Full features (recommended)
= { = "0.2.0", = ["full"] }
# Core functionality only
= { = "0.2.0", = ["core"] }
# Minimal - L1 cache only
= { = "0.2.0", = ["minimal"] }
# Custom selection
= { = "0.2.0", = ["core", "macros", "metrics"] }
| Tier | Features | Description |
|---|---|---|
| minimal | memory, tokio/time, tracing, metrics, serialization, chrono |
L1 cache only |
| core | minimal + redis, futures |
L1 + L2 cache |
| full | core + macros, compression, batch-write, lua-script, cli, testing |
Complete functionality |
Individual Features:
memory- L1 cache backends (Moka + DashMap)redis- L2 distributed cache (Redis)macros-#[cached]attribute macroserialization- JSON serialization (serde + serde_json)compression- Data compression (flate2)metrics- OpenTelemetry metrics and observabilitybatch-write- Optimized batch writing (tokio-util)lua-script- Lua script execution supportcli- Command-line interface (clap)tracing- Structured logging support
2. Configuration
Create a config.toml file:
[]
= 3600
= 30
= "json"
= true
# Two-level cache (L1 + L2)
[]
= "two-level" # "l1" | "l2" | "two-level"
= 600
[]
= 10000
= 300 # L1 TTL must be <= L2 TTL
= 180
= 1000
[]
= "standalone" # "standalone" | "sentinel" | "cluster"
= "redis://127.0.0.1:6379"
[]
= true
= true
= true
= 100
= 50
# L1-only cache (memory only)
[]
= "l1"
= 300
[]
= 5000
= 300
= 120
# L2-only cache (Redis only)
[]
= "l2"
= 7200
[]
= "standalone"
= "redis://127.0.0.1:6379"
2.1 Type-Safe Configuration API (Recommended)
Oxcache provides a type-safe builder API for configuration, enabling compile-time type checking and better IDE support. This approach is recommended over TOML configuration for most use cases.
Memory-Only Cache (L1)
use UnifiedConfigBuilder;
use ;
use ;
async
Tiered Cache (L1 + L2)
use UnifiedConfigBuilder;
use ;
use ;
async
Configuration Builder Methods
| Method | Description |
|---|---|
Cache::builder() |
Create a new cache builder |
.ttl(Duration) |
Set default TTL for cache entries |
.capacity(u64) |
Set memory cache capacity |
.redis(url) |
Configure Redis backend |
.redis_with_mode(url, mode) |
Configure Redis with mode (Standalone/Sentinel/Cluster) |
.tiered(l1_capacity, url) |
Configure tiered cache (L1 + L2) |
.with_backend(backend) |
Use custom backend |
.batch_writes(bool) |
Enable/disable batch writes |
.auto_promote(bool) |
Enable/disable auto-promote from L2 to L1 |
.build() |
Build Cache<K, V> instance |
Benefits of Type-Safe API
- Compile-time validation: Configuration errors caught at compile time
- IDE support: Full autocomplete and type hints
- No runtime parsing: Eliminates TOML parsing overhead
- Better error messages: Type errors instead of configuration parse errors
- Refactoring friendly: Rename refactoring works across configuration
3. Usage
Using Macros (Recommended)
use cached;
use ;
use ;
// One-line cache enable
async
async
Manual Client Usage
use ;
use ;
async
🎨 Use Cases
Scenario 1: User Information Cache
async
Scenario 2: API Response Cache
async
Scenario 3: L1-Only Hot Data Cache
async
🏗️ Architecture
graph TD
A[Application Code<br/>#[cached] Macro] --> B[Cache<K, V><br/>Unified Cache Interface]
B --> C[ChainCache<br/>Tiered Backend]
B --> D[MokaMemoryBackend<br/>L1 Only]
B --> E[RedisBackend<br/>L2 Only]
C --> F[L1 Cache<br/>Moka]
C --> G[L2 Cache<br/>Redis]
D --> F
E --> G
style A fill:#e1f5fe
style B fill:#f3e5f5
style C fill:#e8f5e8
style D fill:#fff3e0
style E fill:#fce4ec
style F fill:#f1f8e9
style G fill:#fdf2e9
L1: In-process high-speed cache using LRU/TinyLFU eviction strategy L2: Distributed shared cache supporting Sentinel/Cluster modes
📊 Performance Benchmarks
Test environment: M1 Pro, 16GB RAM, macOS, Redis 7.0
Note: Performance varies based on hardware, network conditions, and data size.
xychart-beta
title "Single-thread Latency Test (P99)"
x-axis ["L1 Cache", "L2 Cache", "Database"]
y-axis "Latency (ms)" 0 --> 60
bar [0.05, 3, 30]
line [0.05, 3, 30]
xychart-beta
title "Throughput Test (batch_size=100)"
x-axis ["L1 Operations", "L2 Single Write", "L2 Batch Write"]
y-axis "Ops/sec" 0 --> 600
bar [7500, 75, 350]
Performance Summary:
- L1 Cache: 50-100ns (in-memory)
- L2 Cache: 1-5ms (Redis, localhost)
- Database: 10-50ms (typical SQL query)
- L1 Operations: 5-10M ops/sec
- L2 Single Write: 50-100K ops/sec
- L2 Batch Write: 200-500K ops/sec
🛡️ Reliability
- ✅ Single-Flight (prevent cache stampede)
- ✅ WAL (Write-Ahead Log) persistence
- ✅ Automatic degradation on Redis failure
- ✅ Graceful shutdown mechanism
- ✅ Health checks and auto-recovery
🔐 Security
Oxcache implements multiple security measures to protect against common attacks:
Input Validation
All user inputs are validated before being passed to Redis:
- Key Validation: Keys cannot be empty, exceed 512KB, or contain dangerous characters (
\r,\n,\0) that could enable Redis protocol injection attacks. - Lua Script Validation: Scripts are validated for:
- Maximum length of 10KB
- Maximum of 100 keys
- Blocking dangerous commands:
FLUSHALL,FLUSHDB,KEYS,SHUTDOWN,DEBUG,CONFIG,SAVE,BGSAVE,MONITOR - Comment and string content preprocessing to prevent bypass via comments
- SCAN Pattern Validation: Patterns are validated to prevent ReDoS attacks:
- Maximum length of 256 characters
- Maximum of 10 wildcard (
*) characters - Count parameter clamped to safe range (1-1000)
- SQL/Path Traversal Detection: Redis keys are scanned for potential SQL injection and path traversal patterns
Security API (Public Functions)
For advanced use cases, you can directly use the security validation functions:
use ;
// Validate Redis keys
validate_redis_key.expect;
// Validate Lua scripts
validate_lua_script.expect;
// Validate SCAN patterns
validate_scan_pattern.expect;
Timeout Protection
Long-running operations have timeout protection:
- Lua Scripts: 30-second timeout prevents Redis blocking
- SCAN Operations: 30-second timeout prevents hanging scans
Secure Lock Values
Distributed locks use cryptographically secure UUID v4 values automatically generated by the library, eliminating the risk of lock value prediction attacks.
Connection String Redaction
Passwords in connection strings are redacted in logs by default to prevent credential leakage. Use normalize_connection_string_with_redaction() for secure logging.
Best Practices
- Use the library's key validation - Don't bypass the
validate_redis_key()function - Avoid custom Lua scripts - Use the built-in cache operations when possible
- Set appropriate timeouts - Don't disable the 30-second default timeout
- Rotate lock values - The library handles this automatically
- Never log connection strings - Use the redaction utility for debugging
For more details, see Security Documentation.
📚 Documentation
🤝 Contributing
Pull Requests and Issues are welcome!
📝 Changelog
See CHANGELOG.md
📄 License
This project is licensed under MIT License. See LICENSE file.
If this project helps you, please give a ⭐ Star to show support!
Made with ❤️ by Kirky.X