Cache Interface

Overview

The caching system is implemented based on the Rust technology stack, supporting multiple cache storage methods and providing a unified operation interface. The core features and implementation details are as follows:

1. Core Architecture and Design

Multiple Storage Backend Support

The system adopts a design that separates abstract interfaces from concrete implementations, using the Cache enum to uniformly encapsulate two cache backends:

• Redis: Distributed cache, suitable for multi-instance deployment scenarios, relies on bb8-redis connection pool to manage connections.
• Memory: Memory cache, based on DashMap for thread-safe storage, suitable for single-instance lightweight scenarios.

The cache type is specified through the configuration file (cache_type field), with default support for two types: redis and memory.

Core Data Structures

• Cache Enum (src/cache/mod.rs): Unified external interface, dynamically selects Redis or memory implementation based on configuration.
• CacheProvider Trait (src/cache/traits.rs): Defines standard cache operation interfaces, ensuring consistency across different backend implementations.
• MemoryItem Structure (src/cache/memory.rs): Atomic unit of memory cache, containing value, expiration time, and other metadata.

2. Core Features and Interfaces

Basic Key-Value Operations

• String Storage: set_string/get_string for direct string storage, set_string_ex supports setting expiration time (in seconds).
• Serialized Storage: set_value/get_value automatically serializes/deserializes data of any type through serde_json.
• Expiration and Deletion: ttl queries remaining expiration time, remove deletes keys, get_one_use automatically deletes after retrieving the value (one-time key).

Example code:

// Store and automatically serialize objects
let user = User { id: 1, name: "test" };
cache.set_value("user:1", &user).await?;

// Read and deserialize
let user: User = cache.get_value("user:1").await?;

Advanced Data Structures

Supports Redis-style complex data structure operations:

• Lists: lpush adds elements, brpop performs blocking pop of elements.
• Sets: sadd adds members.
• Sorted Sets: zadd adds elements with scores, zrange/zrangebyscore_limit queries elements.

Namespace Isolation

Implements key isolation through the namespace mechanism to avoid key conflicts between different modules:

• Specifies a default namespace during initialization (e.g., qiluo), with key storage format as {namespace}:{key}.
• Can create new namespace instances via with_namespace or dynamically switch via set_namespace.

Cache Management

• Bulk Queries: get_all retrieves all key-value pairs, get_all_paginated supports pagination and keyword search.
• Expiration Cleanup: Memory cache cleans up expired keys through a scheduled task (once per minute), Redis relies on its own expiration mechanism.

3. Implementation Details

Memory Cache (MemoryCache)

• Storage Structures:
  • String key-value pairs: DashMap<String, MemoryItem> (supports concurrent read/write).
  • Lists: DashMap<String, Vec<String>>.
  • Sets: DashMap<String, DashMap<String, bool>>.
  • Sorted Sets: DashMap<String, Vec<(String, f64)>>.
• Expiration Mechanism: Starts a background task to clean up expired items every minute; also checks expiration status and deletes when accessed.

Redis Cache (RedisCache)

• Connection Management: Uses the bb8 connection pool to maintain Redis connections, avoiding the overhead of frequent connection creation.
• Command Mapping: Directly calls Redis commands through the redis crate, ensuring feature completeness.
• Namespace Handling: Automatically adds namespace prefixes to keys; commands like brpop restore original key names when returning.

Global Instance Management

Creates a global cache instance (GLOBAL_CACHE) through OnceCell, ensuring singleton within the application:

// Initialize global cache
CacheManager::init().await?;

// Get instance
let cache = CacheManager::instance().await;

4. Configuration and Initialization

Configuration Parameters (src/config/appconfig.rs)

pub struct CacheConfig {
    pub cache_type: String,    // Cache type: redis/memory
    pub namespace: Option<String>,  // Default namespace
    pub url: Option<String>,   // Redis connection address (required for redis type)
    pub pool_size: Option<u32>,    // Memory cache pool size (required for memory type)
}

Initialization Process

1. Read the configuration file and select the backend based on cache_type.
2. Validate configuration validity (e.g., non-empty Redis URL, non-empty memory pool size).
3. Create the corresponding cache instance and store it in GLOBAL_CACHE.

5. Key Code Modules

Module Path	Functionality
src/cache/mod.rs	Defines the Cache enum and global instance management, unified cache operation entry point.
src/cache/traits.rs	Defines the CacheProvider trait, standardizing cache operation interfaces.
src/cache/memory.rs	Memory cache implementation, including data structures, expiration cleanup, and other logic.
src/cache/redis.rs	Redis cache implementation, based on Redis command mapping.
src/service/sys/s_sys_cache.rs	Provides cache management API (list query, clearing, etc.).

6. Application Scenarios

• System Caching: Stores frequently accessed data such as user sessions and permission information.
• Task Queue Dependencies: Serves as underlying storage for task queues (e.g., scheduled tasks, asynchronous tasks) through lists and sorted sets.
• Interface Performance Optimization: Caches database query results, reducing DB access pressure.

In summary, this caching system implements multi-backend support through a unified interface abstraction, accommodating both distributed and lightweight scenarios, providing rich data structure operations and management functions, suitable for enterprise-level application caching needs.