In modern application development, data storage and caching are critical to improving system performance. As a document - oriented database, MongoDB and Redis, as an in - memory caching database, each have distinct functional focuses. Using MongoDB alone may lead to high - concurrent read/write pressure, while relying solely on Redis is limited by memory and persistence capabilities. This article will introduce how to combine MongoDB and Redis to leverage their respective advantages and optimize system performance.
I. MongoDB and Redis: Their “Specialties”¶
MongoDB: Flexible Storage for Long - Term Data¶
MongoDB is a document - oriented database that stores data in JSON format with flexible structures. It excels at handling semi - structured data (such as user profiles and product details) and supports complex queries and transactions. It is suitable for storing data that needs long - term preservation and may have changing structures. For example:
- Product details in e - commerce platforms (including name, price, images, attributes, etc.)
- User dynamics on social platforms (each dynamic may contain different fields)
However, MongoDB has a drawback: disk I/O is relatively slow, which may become a bottleneck when accessed frequently.
Redis: Fast Response for High - Frequency Caching¶
Redis is an in - memory database, with data directly stored in memory, resulting in extremely fast read/write speeds (tens of times faster than MongoDB). It is suitable for storing high - frequency access, temporary, or hot data and supports various data structures (strings, hashes, lists, sorted sets, etc.). Common use cases include:
- Caching hot data (such as popular product information)
- Session management (such as user login tokens)
- Counters/ranking lists (such as product sales rankings)
But Redis has its limitations: memory capacity is limited, and data persistence (such as RDB/AOF) may have delays. It is not suitable for storing ultra - large amounts of historical data.
II. Why Combine Them?¶
When using MongoDB alone, high - frequency access will cause disk I/O congestion; when relying solely on Redis, a large amount of data will occupy memory and cannot be stored long - term. The combination strategy enables “division of labor and cooperation”:
- MongoDB is responsible for “long - term storage”: It handles data that needs persistence and has complex structures.
- Redis is responsible for “high - frequency caching”: It shares the read/write pressure of MongoDB and improves response speed.
For example, consider an e - commerce website with 1 million product data. MongoDB stores all product information, but the “Top 100 best - selling products” are hot data with high user access frequency. If each request queries MongoDB, it will lead to high database pressure and slow response. At this time, using Redis to cache the information of these 100 products allows user requests to read directly from Redis, which can improve the speed by tens of times.
III. Common Combination Strategy Scenarios¶
1. Caching Hot Data from MongoDB (Most Common)¶
Scenario: MongoDB stores data such as products and articles, and some content (such as popular products) has extremely high access volume.
Approach:
- First, cache hot data in Redis to reduce the query pressure on MongoDB.
- Process: User request → Check Redis (return if available) → If not, check MongoDB → After querying, update Redis cache → Return the result.
Example:
Assume there is a product collection products in MongoDB, and the ID of the popular product is 1001.
- First request: Check Redis (no data) → Check MongoDB (obtain product information) → Store the result in Redis (SET 1001:product product details) → Return.
- Second request: Directly check Redis (has data) → Return the result without querying MongoDB.
Note: The cache needs to be updated regularly to avoid the situation where the Redis data is still old after the MongoDB data changes (for example, when a product is discounted, Redis needs to be updated synchronously).
2. Session Management (User Login Authentication)¶
Scenario: After a user logs in, the system needs to quickly verify the identity and determine user permissions.
Approach:
- Redis stores user session information (such as user ID, token, permissions). The front - end request carries the token, and the back - end checks Redis for verification.
Example:
- After the user logs in successfully, the back - end generates a token (such as user_123), and stores the user information (user_id=123, name=Xiaoming) in Redis (HSET session:user_123 name Xiaoming).
- In subsequent requests, the front - end carries Authorization: user_123, and the back - end can quickly verify the identity by checking Redis without querying MongoDB.
3. High - Frequency Counters and Rankings¶
Scenario: E - commerce sales rankings, article reading counts, like counts, etc., in high - frequency update scenarios.
Approach:
- Redis uses sorted sets to implement rankings and counters (incr) to update likes/sales.
Example:
- Product sales ranking: Use ZADD products_rank sales volume product ID in Redis to update sales volume, and use ZRANGE products_rank 0 99 to obtain the top 100 product IDs, then query MongoDB to get detailed information.
- Like count: INCR post:123:like directly updates the counter, and MongoDB only stores historical like data.
4. Temporary Data Storage (Intermediate Results/Temporary Sessions)¶
Scenario: Temporary file paths uploaded by users, intermediate states of form filling, temporary cache of API interfaces.
Approach:
- Redis stores temporary data (such as file paths with a validity period of 10 minutes), and MongoDB stores long - term data (such as file metadata).
Example:
- After a user uploads an image, Redis stores the temporary path (SET temp:img_123 /upload/temp/xxx.jpg), and MongoDB stores the image metadata (size, format).
IV. “Pitfalls” to Note When Combining¶
1. Cache Penetration: Empty Data Requests Increase MongoDB Pressure¶
Problem: A user requests a non - existent key (such as a non - existent product with ID 9999). Redis has no cache, so it directly queries MongoDB and returns empty. Subsequent requests will repeatedly query MongoDB.
Solution:
- Cache empty values in Redis (such as SET 9999:product "") and set a short - term expiration time (such as 5 minutes) to avoid repeated queries.
- Use a Bloom filter to pre - filter non - existent keys (such as filtering invalid product IDs).
2. Cache Breakdown: Hot Key Expiration Causes MongoDB Collapse¶
Problem: A hot key (such as product ID 1001) expires, and a large number of requests query MongoDB simultaneously, leading to a sudden increase in database pressure.
Solution:
- Set “never expire” for hot keys, or use a lock (such as the SETNX command in Redis) to ensure that only one request queries MongoDB at the same time.
3. Cache Avalanche: A Large Number of Keys Expire Simultaneously Causes MongoDB Pressure¶
Problem: A large number of hot keys in Redis expire simultaneously (such as after a flash sale ends), and all requests immediately flood into MongoDB.
Solution:
- Set random expiration time for keys (such as randomly within ±10% of the fixed expiration time) to avoid centralized expiration.
- Regularly preheat the cache (such as pre - updating hot data in Redis before a flash sale).
V. Summary¶
The combination of MongoDB and Redis essentially realizes “database is responsible for persistent storage, and cache is responsible for high - frequency access acceleration”. By reasonably assigning responsibilities, we can not only leverage MongoDB’s flexible storage capabilities but also utilize Redis’s high - performance advantages to achieve “read - write separation” and “pressure sharing” in the system.
Beginners can start with the simplest “hot data caching” scenario and gradually try combination strategies such as session management and counters. The key points are to focus on the cache update timing and avoid common cache problems. Remember: there is no absolute best combination; it needs to be flexibly adjusted according to business scenarios (high/low frequency, short/long term).