Redis到底能撑多少数据量，存储条数有没有极限啊？

很多人刚开始用Redis的时候,都会有一个印象，觉得它就是个速度快、但容量小的内存数据库，可能也就放几G、十几G的数据，但实际上，这个问题“Redis到底能撑多少数据量？”的答案，远比想象中复杂，它不是一个简单的数字，而是一个“看情况”的问题。Redis能撑多少数据，主要不取决于它能存多少条键值对，而取决于你服务器的内存有多大，以及你怎么用Redis。

我们来谈谈那个“存储条数有没有极限”的问题，从理论上讲，Redis单个实例能存储的键（Key）的数量上限是惊人的 2的32次方 个，这大约是42.9亿个，这个数字对于绝大多数应用场景来说，几乎可以认为是“没有极限”的，你很难遇到一个业务需要存储超过40亿个不同的键，我们通常不用担心Redis本身计数会溢出的问题，真正的瓶颈根本不在这里。

真正的瓶颈在哪里呢？答案就是内存，Redis的所有数据都放在内存里，所以你的数据总量绝对不能超过服务器可用的物理内存大小，这是最硬性的一个限制，你有一台服务器，装了64GB的内存，刨去操作系统和其他程序要用的部分，可能还剩60GB给Redis，你这60GB就是Redis数据库容量的天花板。

但事情还没完,即使内存足够大，你的使用方式也极大地影响了最终能存下多少“有效”数据，这里有几个关键点：

第一,数据类型和值的大小，你存的是什么样的数据？如果你存的都是很小的字符串，比如用户的登录状态标记（true或false），那一条数据可能就几十个字节，但如果你存的是很大的对象，比如一篇完整的文章内容，或者一张经过Base64编码的图片，那一条数据可能就是几MB甚至更大，显然，同样大小的内存，存小对象能存几千万上亿条，存大对象可能几万条就满了，根据Redis官方文档（Antirez）的说明，管理大量小对象比管理少量大对象在效率上会更划算一些。

第二,数据的结构，Redis提供了丰富的数据结构，如String（字符串）、Hash（哈希）、List（列表）、Set（集合）等，选择合适的数据结构能极大节省空间，要存储一个用户的多个字段信息（姓名、年龄、城市），如果用多个独立的String键来存，就会为每个键存储一些额外的管理信息（元数据），造成浪费，但如果用一个Hash结构来存，这些字段作为同一个键内部的子项，就能节省大量内存，这种优化在数据量巨大时效果非常明显。

第三,是否开启持久化，Redis为了数据安全，提供了两种持久化方式：RDB（快照）和AOF（记录所有写命令），开启AOF，尤其是配置为每次写入都同步到磁盘（appendfsync always）时，会对性能有一定影响，但能保证数据安全性，而生成RDB快照时，如果数据量非常大，fork子进程的过程可能会导致服务器短暂停顿（Stop-The-World），这在内存紧张时尤其明显，大数据量下持久化的策略需要精心设计。

第四,淘汰策略，当内存用完时，Redis怎么办？这就需要你设置maxmemory-policy（内存淘汰策略），是报错不让写了？还是淘汰掉最近最少使用的数据（LRU）？或者是随机淘汰？这个策略的选择决定了Redis在达到内存上限时的行为，直接影响业务的连续性，如果你设置的是noeviction（不淘汰），那么数据写满后，所有尝试写入的操作都会失败。

现实中Redis到底能撑多大的数据量呢？根据一些公开的技术实践分享，比如来自知乎等平台上的大型互联网公司工程师的案例，我们可以看到：

• 在常规业务中,一个Redis实例承载几十GB到几百GB数据是非常普遍的，很多公司的缓存层就是这种规模。
• 在一些极端场景下,通过优化（使用更高效的数据结构、升级到64GB甚至更大内存的服务器、使用Redis集群等），单实例承载1TB以上的数据也是有可能的，但这会对运维和性能调优提出非常高的要求。
• 当单机内存无法满足需求时,解决方案不是继续找更大内存的服务器（硬件有极限且昂贵），而是采用分布式方案——Redis Cluster（Redis集群），集群可以将数据分片（sharding）到多台机器上，这样理论上你的数据容量就可以水平扩展，几乎是无限的，一个由100台每台有128GB内存的服务器组成的Redis集群，总容量就是12.8TB。

总结一下：Redis存储条数的理论极限是42亿左右，基本不用考虑，而实际的数据量极限取决于你的“服务器内存大小”和“数据使用模式”。 对于绝大多数应用，单机Redis完全够用，当数据量增长到单机无法承受时，正确的方向是走向Redis集群架构，实现容量的水平扩展，与其纠结一个绝对的数字，不如更多地关注你的业务数据模型设计和未来的扩展方案。