在现代应用开发中，数据存储和缓存是提升系统性能的关键环节。MongoDB作为文档型数据库，Redis作为内存缓存数据库，两者在功能上各有侧重。单独使用MongoDB可能面临高并发读写压力，单独使用Redis则受限于内存和持久化能力。本文将介绍如何通过组合MongoDB和Redis，发挥各自优势，优化系统性能。
一、MongoDB与Redis：各自的“特长”¶
MongoDB：灵活存储，适合长期数据¶
MongoDB是文档型数据库，以JSON格式存储数据，结构灵活。它擅长处理半结构化数据（如用户资料、商品详情），支持复杂查询和事务，适合存储需要长期保存且结构可能变化的数据。例如：
- 电商平台的商品详情（包含名称、价格、图片、属性等）
- 社交平台的用户动态（每条动态可能包含不同字段）
但MongoDB的缺点是：磁盘I/O速度较慢，高频访问时可能成为系统瓶颈。
Redis：快速响应，适合高频缓存¶
Redis是内存数据库，数据直接存储在内存中，读写速度极快（比MongoDB快数十倍）。它适合存储高频访问、临时或热点数据，支持多种数据结构（字符串、哈希、列表、有序集合等），常见用途包括：
- 热点数据缓存（如热门商品信息）
- 会话管理（如用户登录令牌）
- 计数器/排行榜（如商品销量排名）
但Redis的缺点是：内存容量有限，数据持久化（如RDB/AOF）可能延迟，不适合存储超大量历史数据。
二、为什么要组合使用？¶
单独使用MongoDB时，高频访问会导致磁盘IO堵塞；单独使用Redis时，大量数据会占用内存且无法长期存储。组合策略可以实现“分工协作”：
- MongoDB负责“长期存储”：处理需要持久化、结构复杂的数据。
- Redis负责“高频缓存”：分担MongoDB的读写压力，提升响应速度。
举个例子：假设一个电商网站有100万商品数据，MongoDB存储所有商品信息，但“销量Top100的商品”是用户高频访问的热点。如果每次请求都查MongoDB，会导致数据库压力大、响应慢。此时用Redis缓存这100个商品的信息，用户请求直接从Redis读取，速度提升数十倍。
三、常见组合策略场景¶
1. 缓存MongoDB中的热点数据（最常用）¶
场景：MongoDB中存储商品、文章等数据，部分内容（如热门商品）访问量极高。
做法：
- 热点数据先缓存到Redis，减少MongoDB查询压力。
- 流程：用户请求→查Redis（有则返回）→无则查MongoDB→查到后更新Redis缓存→返回结果。
示例：
假设MongoDB中有商品集合products，热门商品ID为1001。
- 第一次请求：查Redis（无数据）→查MongoDB（获取商品信息）→将结果存入Redis（SET 1001:product 商品详情）→返回。
- 第二次请求：直接查Redis（有数据）→返回结果，无需查MongoDB。
注意：缓存需定期更新，避免MongoDB数据变化后Redis数据仍为旧值（如商品降价时，Redis需同步更新）。
2. 会话管理（用户登录身份验证）¶
场景：用户登录后，系统需快速验证身份，判断用户权限。
做法：
- Redis存储用户会话信息（如用户ID、token、权限），前端请求携带token，后端查Redis验证。
示例：
- 用户登录成功后，后端生成token（如user_123），并将用户信息（user_id=123, name=小明）存入Redis（HSET session:user_123 name 小明）。
- 后续请求中，前端携带Authorization: user_123，后端查Redis即可快速验证身份，无需查询MongoDB。
3. 高频计数器与排行榜¶
场景：电商销量排名、文章阅读量、点赞数等高频更新场景。
做法：
- Redis用有序集合（sorted set） 实现排行榜，用计数器（incr） 实现点赞/销量更新。
示例：
- 商品销量排行榜：Redis中用ZADD products_rank 销量 商品ID更新销量，用ZRANGE products_rank 0 99获取Top100商品ID，再查MongoDB获取详细信息。
- 点赞数：INCR post:123:like直接更新计数器，MongoDB仅存储历史点赞数据。
4. 临时数据存储（中间结果/临时会话）¶
场景：用户上传的临时文件路径、表单填写的中间状态、API接口的临时缓存。
做法：
- Redis存储临时数据（如有效期10分钟的文件路径），MongoDB存储长期数据（如文件元信息）。
示例：
- 用户上传图片后，Redis存临时路径（SET temp:img_123 /upload/temp/xxx.jpg），MongoDB存图片元信息（尺寸、格式）。
四、组合时需注意的“坑”¶
1. 缓存穿透：空数据请求导致MongoDB压力暴增¶
问题：用户请求一个不存在的key（如商品ID为9999的不存在商品），Redis中无缓存，直接查MongoDB也返回空，后续每次请求都会重复查MongoDB。
解决：
- Redis中缓存空值（如SET 9999:product ""），设置短期过期时间（如5分钟），避免重复查询。
- 用布隆过滤器提前过滤不存在的key（如过滤无效商品ID）。
2. 缓存击穿：热点key过期导致MongoDB崩溃¶
问题：一个热点key（如商品ID1001）过期后，大量请求同时查MongoDB，导致数据库压力骤增。
解决：
- 热点key设置“永不过期”，或加锁（如Redis的SETNX命令），确保同一时间只有一个请求查MongoDB。
3. 缓存雪崩：大量key同时过期导致MongoDB压力¶
问题：Redis中大量热点key同时过期（如秒杀活动结束后），所有请求瞬间涌入MongoDB。
解决：
- 给key设置随机过期时间（如在固定过期时间±10%内随机），避免集中过期。
- 定期预热缓存（如秒杀前提前更新Redis中的热点数据）。
五、总结¶
MongoDB与Redis的组合，本质是“数据库负责持久化存储，缓存负责高频访问加速”。通过合理分配职责，既能发挥MongoDB的灵活存储能力，又能利用Redis的高性能优势，实现系统“读写分离”和“压力分担”。
初学者可以从最简单的“热点数据缓存”场景入手，逐步尝试会话管理、计数器等组合策略，重点关注缓存更新时机和避免常见缓存问题。记住：没有绝对的最佳组合，需根据业务场景（高频/低频、短期/长期）灵活调整。