Redis 多数据库 DB 0 到 DB 15 适合用来做业务隔离吗？

简化版

Redis 的多个逻辑 DB 只是同一实例内的命名空间隔离，不适合做强业务隔离。它们共享 CPU、内存、持久化、慢命令、淘汰策略和故障影响。生产上更推荐用不同实例、不同集群或 key 前缀加权限管理来隔离。

详细版

Redis 默认有多个逻辑数据库，可以用 SELECT 0、SELECT 1 切换。但这些 DB 仍在同一个 Redis 进程里，资源完全共享。

如果 A 业务在 DB 1 执行慢命令、写入大 key 或占满内存，B 业务在 DB 2 也会受影响。持久化文件、复制、故障恢复也不是按 DB 独立运作。

所以多 DB 适合简单开发或少量工具隔离，不适合生产上把多个重要业务混在一个实例里。Redis Cluster 也通常只支持 DB 0，这进一步说明多 DB 不是现代 Redis 集群隔离方案。

完整版教学

一、多 DB 是什么

Redis 单实例可以配置多个逻辑数据库，默认常见编号是 0 到 15。客户端连接后可以通过 SELECT index 切换当前 DB。

SELECT 1
SET user:1 Tom
SELECT 2
GET user:1

在 DB 2 读不到 DB 1 的 user:1，所以它看起来像隔离。但这只是 key 命名空间隔离，不是资源隔离。

二、为什么它隔离不了资源

所有逻辑 DB 共享同一个 Redis 主线程、同一份内存、同一个持久化流程和同一个网络服务。一个 DB 里的慢命令会占住执行路径，其他 DB 的请求也要排队。

假设 DB 1 有后台任务执行 KEYS *，DB 0 的核心缓存 GET 也会被影响。因为 Redis 调度命令时不是给每个 DB 单独一套 CPU。

DB0: 核心订单缓存
DB1: 后台统计缓存

共享：进程、CPU、内存、AOF/RDB、网络、故障半径

三、内存和淘汰也不是独立的

maxmemory 针对实例，不是某个 DB。DB 1 写满内存后，可能触发全实例淘汰策略，DB 0 的 key 也可能被影响。

维度	多 DB 是否独立	说明
key 命名空间	相对独立	同名 key 可在不同 DB 存在
CPU	不独立	共享主线程
内存上限	不独立	maxmemory 是实例级
持久化	不独立	RDB/AOF 覆盖实例
故障	不独立	实例挂了全部 DB 受影响

这就是为什么生产隔离不能只靠 DB 编号。

四、Redis Cluster 下的限制

Redis Cluster 模式通常只支持 DB 0，不支持通过 SELECT 切换多个数据库。因为 Cluster 已经通过槽位分布管理 key，多 DB 会让路由、迁移和一致性更复杂。

如果业务未来要迁移到 Cluster，早期依赖多 DB 会增加改造成本。更稳的是从一开始用 key 前缀、实例隔离或集群隔离。

例如 order:cache:*、user:session:*、risk:feature:* 通过前缀区分，再配合 ACL 和实例规划。

五、正确的隔离方式怎么选

轻量隔离可以用 key 前缀，配合规范和 SDK 封装，防止 key 冲突。中等隔离可以不同业务用不同 Redis 实例。强隔离则需要不同集群、不同账号权限、不同资源配额和独立监控。

如果两个业务的重要性、流量峰值、数据生命周期不同，最好不要混在同一个实例里。比如验证码、排行榜和订单核心缓存就不应该随便共享一个小实例。

隔离的本质是控制故障半径，而不是让 key 名看起来不冲突。

六、常见误区与追问

• 误区：DB 编号不同就像不同数据库实例。 它们只是逻辑命名空间，资源和故障仍共享。
• 误区：用多 DB 可以避免内存互相影响。 maxmemory 和淘汰策略是实例级的。
• 误区：开发环境方便的方式可以直接搬到生产。 多 DB 在生产会带来迁移和隔离风险。
• 追问：Redis Cluster 能用多个 DB 吗？ 通常只使用 DB 0，不能依赖 SELECT 做多 DB 隔离。
• 追问：业务隔离推荐怎么做？ 用实例/集群隔离，辅以前缀规范、ACL、监控和容量配额。

七、加强记忆

记忆钩子：Redis 多 DB 像同一间办公室里的不同抽屉，文件名不冲突，但空调、门锁、断电和噪音都是共享的。

回答这题时抓住“命名空间隔离不等于资源隔离”。把 CPU、内存、持久化、淘汰、故障半径和 Cluster 限制讲清楚，结论自然就是生产不要滥用多 DB。