那是一個普通得不能再普通的下午。我端着一杯已經涼了的美式，坐在視頻面試前，心想：
“Redis 我天天用，緩存、分佈式鎖、限流、秒殺，閉着眼都能聊。”
面試官一開口也很友好：
“Redis 用得多吧？”
我自信點頭。
“那我問個簡單點的，Redis 為什麼設計了 16 個數據庫？”
我愣住了。不是因為不會用 Redis，而是因為我從來沒認真想過這個問題。
我腦子裏飛快地閃過無數場景：
- select 0
- select 1
- 配置文件裏的 databases 16
- 面試題裏偶爾出現的“多庫隔離”
但“為什麼是 16”，不是 8，也不是 32，更不是 1？
那一刻，我感覺自己像一個每天開車上下班，卻突然被問：
“方向盤為什麼是圓的？”
先別急，咱把 Redis 的「16 庫」當成一棟公寓
在解釋技術之前，我想先講個更生活化的故事。假設你是房東，買了一棟 16 層的小公寓。
- 每一層都有獨立的房門
- 每一層都能住人
- 但這 不是 16 棟樓，而是 一棟樓的 16 層
這棟樓有幾個特點：
- 水電是共用的
- 電梯是同一部
- 承重結構是一樣的
Redis 的 16 個庫，本質上就是這棟樓裏的 16 層。它們：
- 邏輯上隔離
- 物理上共享同一塊內存、同一個進程
很多人一聽“16 個數據庫”，就誤以為：
“哇，那是不是和 MySQL 一樣？隔離得很徹底？”
不不不。Redis 設計這 16 個庫，從一開始就沒打算讓你拿它當關系型數據庫來用。
Redis 的數據庫，到底是個什麼東西？
先看一眼 Redis 的配置文件：
啓動 Redis 後，默認就在 0 號庫：
切換數據庫：
每個庫：
- 都有自己的一套 key
- key 之間互不衝突
- 但 內存是共享的
我們可以用一個簡單示例感受一下：
結果是：
看起來很像“隔離”。但別高興太早。這個問題，才是面試官真正想聽的。
歷史原因：最初只是一個“夠用就好”的設計
Redis 最早的目標非常簡單：
快、輕、單線程、內存級
它並不是為了做複雜的多租户數據庫。16 這個數字，在工程裏是個很微妙的存在：
- 是 2 的冪
- 二進制友好
- 足夠做簡單隔離
- 又不會讓管理複雜度爆炸
在 Redis 作者的思路里：
“你最多也就用幾個庫，16 個，綽綽有餘。”
而事實證明大部分人，連第 1 個庫都沒用完。
工程現實：多庫 ≠ 多實例
這是一個非常重要、卻常被忽略的點。
Redis 的 16 個庫：
- 沒有內存配額
- 沒有 QPS 限流
- 沒有權限隔離
如果 0 號庫被一個大 Key 撐爆了內存，1～15 號庫一起陪葬。所以 Redis 從來沒打算：
“讓你用數據庫編號做強隔離。”
那為什麼不是 32、64，甚至 256？
這是很多人面試時會追問的一刀。答案其實很工程化：
Redis 作者的核心取捨是——簡單優先
- 每多一個庫
- 就多一份維護成本
- 多一層心智負擔
- 多一個潛在誤用場景
而 Redis 的定位非常清晰：一個實例 = 一個邏輯服務
如果你真的需要：
- 嚴格隔離
- 不同配置
- 不同持久化策略
Redis 給你的答案不是：“多用幾個庫”，而是：
多起幾個 Redis 實例
一個你可能不知道的真相：Redis 官方並不鼓勵你用多庫
這個點，在社招面試裏屬於加分項。你可以這麼説：
Redis 雖然支持 16 個數據庫，但在生產環境中，官方和社區更推薦 一個實例只用一個庫，通過 key 命名空間 或 多實例 來做隔離。
舉個例子：
而不是：
為什麼？
- Cluster 模式 不支持多庫
- 遷移、擴容、監控更簡單
- 避免 select 帶來的隱式狀態問題
面試官真正想考你的，其實不是“16”
我後來覆盤那次面試，才意識到：面試官根本不在乎你記不記得 16，他在乎的是：你有沒有工程思維
他想聽的，往往是這些點：
- Redis 的多庫是邏輯隔離
- 共享內存、共享進程
- 不適合做強隔離
- 更推薦多實例或 key 前綴
- Cluster 下直接廢掉
如果你能把這些串起來講，“16”只是一個引子。
一個面試級回答模板（你可以直接背）
Redis 設計 16 個數據庫，主要是為了提供一種輕量級的邏輯隔離手段，滿足簡單場景下的 key 分類需求。
但這些數據庫並不是物理隔離的，它們共享同一個進程和內存，因此不適合用於多租户或強隔離場景。
在生產環境中，Redis 官方和社區更推薦使用單庫，通過 key 前綴或多實例的方式進行隔離。
同時，在 Redis Cluster 模式下已經不支持多數據庫，這也進一步説明多庫並不是 Redis 的核心設計方向。
説完這段，面試官大概率會點頭。
寫在最後：別被“簡單問題”騙了
Redis 為什麼是 16 個庫？這個問題，看起來簡單，但背後藏的是：
- 設計哲學
- 工程取捨
- 真實生產經驗
很多社招面試題，問的從來不是“你記住了多少”，而是：你有沒有真的用腦子思考過技術為什麼這樣設計。
如果你也曾在面試裏被這種問題“卡殼”，別慌。下一次，你就可以像個老司機一樣，慢慢講，講清楚，講到位。
END
我是小米！我們，下篇再見。
我是小米，一個喜歡分享技術的31歲程序員。如果你喜歡我的文章，歡迎關注我的微信公眾號“軟件求生”，獲取更多技術乾貨！
