用了十年 Redis，我第一次认真思考“16 个库”这件事

那是一个普通得不能再普通的下午。我端着一杯已经凉了的美式，坐在视频面试前，心想：

“Redis 我天天用，缓存、分布式锁、限流、秒杀，闭着眼都能聊。”

面试官一开口也很友好：

“Redis 用得多吧？”

我自信点头。

“那我问个简单点的，Redis 为什么设计了 16 个数据库？”

我愣住了。不是因为不会用 Redis，而是因为我从来没认真想过这个问题。

我脑子里飞快地闪过无数场景：

select 0select 1配置文件里的 databases 16面试题里偶尔出现的“多库隔离”

但“为什么是 16”，不是 8，也不是 32，更不是 1？

那一刻，我感觉自己像一个每天开车上下班，却突然被问：

“方向盘为什么是圆的？”

先别急，咱把 Redis 的「16 库」当成一栋公寓

在解释技术之前，我想先讲个更生活化的故事。假设你是房东，买了一栋 16 层的小公寓。

每一层都有独立的房门每一层都能住人但这 不是 16 栋楼，而是 一栋楼的 16 层

这栋楼有几个特点：

水电是共用的电梯是同一部承重结构是一样的

Redis 的 16 个库，本质上就是这栋楼里的 16 层。它们：

逻辑上隔离物理上共享同一块内存、同一个进程

很多人一听“16 个数据库”，就误以为：

“哇，那是不是和 MySQL 一样？隔离得很彻底？”

不不不。Redis 设计这 16 个库，从一开始就没打算让你拿它当关系型数据库来用。

Redis 的数据库，到底是个什么东西？

先看一眼 Redis 的配置文件：

启动 Redis 后，默认就在 0 号库：

切换数据库：

每个库：

都有自己的一套 keykey 之间互不冲突但 内存是共享的

我们可以用一个简单示例感受一下：

结果是：

看起来很像“隔离”。但别高兴太早。这个问题，才是面试官真正想听的。

历史原因：最初只是一个“够用就好”的设计

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岁程序员。如果你喜欢我的文章，欢迎关注我的微信公众号“软件求生”，获取更多技术干货！