Redis默认16个库？
兄弟们，今天咱来唠个有意思的事儿 —— 为啥 Redis 默认整了 16 个库？是不是平时用 Redis 的时候，就知道SELECT 0切库，压根儿没想过为啥是 16 这个数？咱先不说答案，先聊聊 Redis 这玩意儿的历史和设计思路。
Redis 刚诞生那会，定位就不是个简单的键值存储，而是想做个多功能的数据结构服务器。早期的 Redis 作者 Salvatore Sanfilippo（也就是咱说的 antirez），估计压根儿没想到这玩意儿后来能火成这样，所以很多设计都是奔着 “简单够用” 去的。就像库的设计，最开始可能就是想弄个简单的 namespace 机制，让不同业务的数据能分开存，省得互相干扰。
那为啥偏偏是 16 呢？这里面可有不少道道儿。咱先从代码层面瞅一眼，在 Redis 的源码里，有个REDIS_DEFAULT_DBNUM宏定义，值就是 16。这时候可能有兄弟问了：“为啥不整个 10 个或者 20 个？这 16 有啥特殊的？” 别急，咱慢慢掰扯。
一、从二进制位说起，16 是 2 的幂次
搞计算机的兄弟都知道，2 的幂次在二进制操作里那叫一个方便。16 等于 2 的 4 次方，这在很多底层操作上能省不少事儿。比如说，在表示库的索引时，4 个二进制位就够了，能大大节省内存空间。而且像位运算这种操作，速度贼快，这对追求高性能的 Redis 来说，可是很重要的一点。
咱再看看 Redis 的配置文件，里面有个database参数，默认值就是 16。如果咱想改这个数，直接改配置就行。但为啥 antirez 当初选了 16 呢？除了 2 的幂次这个原因，还有可能和早期 Redis 的使用场景有关。
二、早期使用场景的影响
早期用 Redis 的场景，大多是简单的缓存或者小型的数据存储，业务没那么复杂，16 个库基本能满足需求。比如说，一个项目里可能有用户数据、订单数据、缓存数据等，16 个库足够把这些不同类型的数据分开存了。而且对于小项目来说，可能压根儿用不了这么多库，16 个库既够用又不会显得太多。
要是弄个 100 个库，对小项目来说，可能反而成了负担，毕竟平时可能就用一两个库，剩下的全闲着，看着也闹心。所以从早期的使用场景来看，16 个库是个比较折中的选择，既能满足基本的分库需求，又不会因为库太多而显得臃肿。
三、兼容性和习惯的延续
Redis 从诞生到现在，版本迭代了很多次，但默认 16 个库这个设置一直没咋变。这其实也和兼容性有关。要是突然把默认库数改成别的数，比如 10 个或者 20 个，那些依赖默认库数的程序可能就会出问题。虽然可以通过配置改，但为了保证兼容性，保持默认值不变是更稳妥的做法。
而且用了这么多年，大家都习惯了 Redis 默认 16 个库，突然改了反而容易让人不适应。就像咱平时用惯了某个工具的快捷键，突然改了快捷键，用起来就会手忙脚乱。所以从兼容性和用户习惯的角度来说，保持 16 个库的默认设置是很合理的。
四、实际应用中库的使用现状
现在咱再看看实际应用中，有多少人真的在用 Redis 的多个库。说实话，估计很多兄弟都是用默认的 0 号库，压根儿没咋换过库。为啥呢？因为现在很多项目都用 Redis 集群了，集群模式下，库的概念被弱化了，更多是通过哈希槽来分片数据。
而且在分布式系统中，分库的需求其实可以通过其他方式来满足，比如在键名里加前缀，像user:1001、order:2001这样，通过键名来区分不同业务的数据，比切库更灵活方便。所以现在很多人可能都忘了 Redis 还有库这个概念，更别说关心为啥默认是 16 个库了。
五、如果需要更多库怎么办？
虽然大多数情况下 16 个库够用，但万一咱真有特殊需求，需要更多的库咋办？其实很简单，改配置就行。在 Redis 的配置文件里，把database参数改成你想要的数，比如 32 或者 64，然后重启 Redis 就 OK 了。
不过咱得注意，改库数的时候，得考虑一下实际需求，别盲目追求库多。因为库数越多，在切换库的时候可能会有一丢丢性能损耗，虽然这点损耗可能微乎其微，但作为严谨的程序员，咱还是得心里有数。
总结
说了这么多，咱来总结一下为啥 Redis 默认 16 个库：
16 是 2 的幂次，在二进制操作和内存表示上更方便高效；
符合早期 Redis 的使用场景，能满足基本的分库需求；
为了保持兼容性和用户习惯，这么多年一直没改；
实际应用中，很多人其实不咋用多个库，16 个库足够了。
怎么样，兄弟们，这下明白为啥 Redis 默认 16 个库了吧？以后面试的时候，要是被问到这个问题，可别再懵圈了，咱得能把这其中的道道儿说清楚。其实编程这事儿就是这样，很多看似简单的设计背后，都有其深层次的考量，多琢磨琢磨这些细节，对咱提升技术水平很有帮助。