Redis到底内置了几个数据库啊，还是说它自带的数据库是啥来着？

你问Redis到底内置了几个数据库，它自带的数据库是啥，这个问题问得非常直接，也确实是很多刚开始用Redis的人会有的一个疑惑。Redis确实自带了多个数据库，默认的数量是16个，但这只是默认情况，而且这个特性在实际使用中，尤其是在现代的应用开发里，已经变得不那么重要，甚至有点“过时”了，下面我详细给你讲讲这是怎么回事,信息主要来源于Redis的官方文档以及社区中常见的实践讨论。

这个“数据库”的概念和你平时理解的MySQL那种有完整表结构的数据库完全不同，在Redis里，它更像是一个简单的“编号”或者“命名空间”，你可以把它想象成一个大楼里的很多个房间，默认这栋楼有16个房间，编号从0到15，你所有的数据，比如键值对、列表、集合等等，都是放在这些房间里的，当你连接上Redis服务器时，默认会进入0号房间（也就是0号数据库），你可以通过一个非常简单的命令 SELECT <数字> 来切换房间，比如输入 SELECT 1，你就切换到了1号数据库，接下来你执行的所有操作，比如设置一个键 SET mykey hello，这个 mykey 就会被存放在1号数据库里，你再 SELECT 0 切回0号数据库，在0号数据库里是找不到 mykey 的。

Redis的设计者当初为什么要设计成多个数据库呢？主要是为了在一个Redis实例（也就是一个Redis服务器进程）内，实现一定程度的数据隔离，比如在开发的早期阶段，你可能会想：我把测试环境的数据放在1号数据库，生产环境的数据放在0号数据库，这样好像挺方便的，不用起两个Redis服务器，或者，一个应用程序的不同模块，可以分别使用不同的数据库,避免键名冲突。

为什么现在大家反而不怎么用这个功能了呢？ 原因有几个,这也是理解现代Redis用法的关键。

第一，隔离性非常差，这16个“房间”虽然号码不同，但它们都在同一个“大楼”里，这意味着它们共享同一个Redis进程的资源，如果一个数据库（比如0号库）里存了超级多的数据，或者有非常耗时的操作，它会占满整个Redis的CPU和内存，导致其他所有数据库（1到15号）的性能都跟着一起下降，这根本达不到真正的隔离效果，真正的隔离应该是各自有独立的资源,互不影响。

第二，管理起来很麻烦，而且有风险，Redis有一些命令是能够跨数据库操作的，FLUSHALL 命令，它会清空所有16个数据库里的所有数据，不管你当前在哪个数据库下，如果你不小心在生产环境执行了这条命令，那将是灾难性的，虽然也有只清空当前数据库的 FLUSHDB 命令,但误操作的风险依然存在。

第三，分布式架构下这个功能基本失效，现在稍微有点规模的系统，都会用到Redis的集群模式，Redis集群是为了把海量数据分布到多台机器上来存储和处理的。在Redis集群模式下，是不支持 SELECT 命令的，只有一个数据库，那就是0号数据库。 这是因为集群的核心是把数据通过算法分到不同的节点上，如果再允许有多个数据库，数据分片就会变得极其复杂，甚至无法实现，一旦你的业务增长需要用到Redis集群，你之前依赖多数据库的代码就得全部重构,把数据迁移到不同的键名设计或者不同的Redis实例上去。

第四，有更好的替代方案，既然内置的数据库隔离性不好，那怎么实现真正的隔离呢？现在的标准做法是：直接运行多个Redis实例。 你可以在同一台机器上启动多个Redis进程，每个进程监听不同的端口（比如6379给生产环境，6380给测试环境），这样，它们在操作系统层面就是完全独立的进程，一个挂了或者变慢，不会影响另一个，资源（内存、CPU）也可以进行独立的限制和监控，配合Docker等容器技术,部署多个实例更是轻而易举。

回到你的问题：Redis到底内置了几个数据库？答案是：默认16个，编号0-15。 但它自带的这个数据库机制，更像是一个历史遗留的、为简单场景设计的功能，对于现在绝大多数严肃的、尤其是准备未来扩展的项目，最佳实践是：就使用默认的0号数据库，然后通过部署多个独立的Redis实例来实现不同环境、不同应用之间的数据隔离。

换句话说，你可以把这个“多数据库”的特性当作一个了解Redis历史的小知识，但在实际写代码和做架构设计时，最好假装它不存在，直接习惯使用一个数据库（0号库）的模式，这样你的应用才能更容易地适应未来的发展，比如平滑地迁移到Redis集群，希望这个解释能让你彻底明白Redis这个“自带数据库”是怎么回事了。