大家好，我是小米，一个 31 岁、依然在互联网行业打怪升级的技术人。
今天要跟你聊一个我在 社招面试中差点翻车的问题：
“Redis 集群模式下，如何选择数据库？为什么很多项目只能用 0 号库？”
这个看似简单，却能把无数 Java 工程师搞得满头问号。更离谱的是，面试官往往喜欢用这道题来判断你对 Redis 架构底层原理是否真正吃透。
今天，我就用一个我亲身经历的“小故事”，带你从懵逼到通透，一次把 Redis Cluster、DB 概念、键槽、迁移、为什么只有 0 号库 全说清楚。
准备好了吗？故事开始啦。
面试前夜：我被“数据库数量”绊倒了上个月，我在准备一次社招面试。为了系统复习 Redis，我把笔记翻出来，看到一条不起眼的记录：
“Redis 默认有 16 个数据库（0-15）。”
我想：不就是 SELECT 2 切换数据库吗？太简单了！
但就在我准备继续往下看时，我突然脑袋一抽：
“等一下……Redis 集群 模式下，还有多个 DB 吗？
我们线上 RedisCluster 好像只有 0 号库？
为什么？？？”
并且我越想越怕：
“大厂面试会不会问这个？？？”
结果第二天，面试官真的问了……
面试现场：面试官一句话，我当场石化面试官推推眼镜，轻描淡写地说：
“我们线上 RedisCluster 只用 0 号 DB，你知道为什么吗？”
我的脑子当场爆炸，所有知识像上线时的缓存击穿一样瞬间失效。
我试探性回答：
“因为……集群模式不支持切换数据库？”
面试官点点头：
“那具体为什么？底层原理你能说说吗？”
我（内心）：完了，这道题我知识点不够，白给了。但我不能怂，于是我尽力从记忆里拼凑答案…
可说实话，当下我答得很一般。回家后，我决定彻底把这个问题搞透。然后，就有了你现在看到的这篇文章。
要回答这个问题，我们必须从 Redis 朝我翻白眼的“根本原因”说起。
原因一：Redis Cluster 的数据分片依赖槽位（slot），与 DB 机制天然冲突Redis Cluster 的核心设计哲学是：
全局只有一份槽位映射表（0~16383 共 16384 个）
每个 key 会根据 CRC16 算法计算 hash，然后映射到槽位：
slot = CRC16(key) % 16384
槽位对应节点 → 节点存储数据 → 集群分片实现
简单直白：
槽位机制确保同一个 key 一定落在同一个节点上。
但是！但是！数据库号（DB index）干嘛用的？
同一个 Redis 实例内部，分隔不同的数据空间。
这就尴尬了：
如果 Redis Cluster 支持多 DB，那么同一个 key 的数据会因为 DB 不同而分布到不同节点，整个槽位映射会瞬间崩溃。
你不能让：
user:1 在 DB0 的 1000 号槽位
user:1 在 DB2 的 9000 号槽位
这会让 Redis Cluster 完全不知道：
“到底哪个才是正确的数据？到底该迁移哪个槽位？到底谁负责这个 key？”
槽位规则会被彻底破坏。因此作者（Antirez）说过一句非常明确的话：
Redis Cluster never supported multiple databases.Only DB 0 is allowed.
原因二：集群节点之间需要迁移槽位，而多 DB 无法同步槽位元数据Redis Cluster 会做槽位迁移，比如扩容缩容时：
migrate slot 5500 from node A → node B
如果支持多 DB，迁移逻辑会爆炸：
每个 DB 维护一份槽位映射？
每个 DB 都要迁移？
槽位在某个 DB 中不存在怎么办？
复杂度直线上升，并且毫无必要。于是 Redis 源码中针对 cluster 直接写死：
没错，就是写死的。就是这么绝情。
Redis 集群为什么干脆“只保留一个 DB”？这里有两个架构设计哲学：
1. 集群场景强调“分布式一致性”，不是“逻辑隔离”
数据库号是一个“逻辑概念”，而 Redis Cluster 的目标是“分布式可扩展性、容错性、数据一致性”。
为了这三个目的，多 DB 反而是负担。
2. 多 DB 的隔离性太弱，不符合大型系统需求
让你想想：
多租户？
多项目？
数据隔离？
权限隔离？
安全管理？
你会用“Redis 的 0-15 DB”吗？你敢吗？不敢。
成熟项目都是：
多个 Redis 实例隔离
多个 Redis Cluster 隔离
DB 分区对大型系统来说是完全不够用的。因此 Redis 作者很早就决定：
单机可以玩 DB
集群模式一律只有 0 号库
干脆利落。
那 Java 项目要如何“模拟多数据库”？标准方法有三种：
方案一：使用不同的 key 前缀（最常用）
例如：
prod:user:1001
test:user:1001
appA:config:*
appB:session:*
Java 中可以通过 RedisTemplate 自动加前缀。
优点：简单
缺点：需要管理 key 前缀格式
方案二：使用多个 Redis 实例
例如：
用户缓存 Redis
订单缓存 Redis
会话 Session Redis
物理隔离，最安全。
方案三：使用多个 Redis Cluster（更大规模）
微服务架构常见设计：
用户域使用 user-redis-cluster
搜索域使用 search-redis-cluster
交易域使用 trade-redis-cluster
真正做到资源隔离、故障隔离、扩容独立。
如果面试官问：Redis Cluster 能不能 SELECT 其他 DB？你要这么回答（必杀技）：
“Redis Cluster 强制只使用 DB0，因为集群的分片依赖 16384 槽位，而多 DB 会破坏槽位映射的一致性，并影响槽位迁移、节点扩容和数据分布。因此 Redis 作者直接在源码中禁用了多 DB，避免出现分布式数据紊乱。”
面试官会觉得：
“这人懂架构，不是只会用 API。”
同款面试题还能顺手引申：
Redis Cluster 的分片机制
Redis 的扩容缩容
为什么 key 必须能被 CRC16 hash
为什么 hash tag（{xxx}）会出现
为什么不要用 keys *
这些都是加分点。
我如何把这道题补强到“面试官满意程度”？我把这道题整理成了 标准面试答案模板（你可以直接记住）：
标准面试总结（1 分钟完美回答）
Redis Cluster 只支持 DB0，不支持 SELECT 切库，原因是：
Redis Cluster 基于槽位分片机制（16384 slots），所有 key 通过 CRC16 落到槽位，而槽位分片是整个集群的数据一致性基础。
多 DB 会破坏槽位模型，会导致相同 key 在不同 DB 中产生不同槽位，使节点无法判断 key 的真正归属。
会导致槽位迁移复杂度暴增，迁移需要处理所有 DB，甚至槽位元数据会无法维护。
因此 Redis 在源码里直接写死：Cluster 模式只允许 0 号数据库。
多数据库需求应通过 前缀隔离、多个实例、多个集群 来实现，不推荐使用 Redis 的 DB 概念。
只要你能说到这些点，面试官基本会觉得你：
“不仅知道答案，还理解架构。”
故事尾声：我在下一次面试实现“完美反杀”一周后，我又去面了另外一家。面试官同样问：
“讲讲 Redis 集群为什么只有 0 号数据库？”
这次我胸有成竹，一套逻辑清晰的回答下来，面试官直接说：
“很好，你理解得很扎实。”
那一刻，我真的感觉：
技术的魅力不只是会用，而是——懂得为什么。
这道题从前让我害怕，现在却成了我面试的加分项。希望你看完这篇文章后，也能从容面对。
END当你理解一个知识背后的“设计哲学”时，它就不再是面试题，而是属于你的武器。
今天的 Redis 故事，希望能帮你补齐这块底层短板，在下一次面试里稳稳拿分。
如果你觉得这篇文章对你有帮助，别忘了点个 在看 或 收藏，这样我就知道要继续写更多类似的内容啦！
