那是一个普通得不能再普通的下午。我端着一杯已经凉了的美式，坐在视频面试前，心想：
“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岁程序员。如果你喜欢我的文章，欢迎关注我的微信公众号“软件求生”，获取更多技术干货！
