在現代應用開發中，數據存儲和緩存是提升系統性能的關鍵環節。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的高性能優勢，實現系統“讀寫分離”和“壓力分擔”。
初學者可以從最簡單的“熱點數據緩存”場景入手，逐步嘗試會話管理、計數器等組合策略，重點關注緩存更新時機和避免常見緩存問題。記住：沒有絕對的最佳組合，需根據業務場景（高頻/低頻、短期/長期）靈活調整。