6.2 内存数据库

6.2 内存数据库

本节摘要：内存数据库不是把磁盘上的数据原样搬进内存跑，而是把内存当作一级存储、把磁盘降为备份。这样一来，索引结构、并发控制、持久化策略都要跟着重写。本节从 Redis 的持久化讲起，讲清内存库为什么快、快在哪，以及 RDB、AOF 这两条持久化路径各自的代价，帮你看清"内存为一级存储"背后的硬件前提和常见坑。读完后，你应当能判断一个场景该用纯缓存还是带持久化的内存库，以及能不能接受它固有的丢失窗口。

上手前先明确

阅读完本节，你应当能够：

1. 说清内存数据库与"给传统库加内存缓存"的本质区别
2. 解释为什么内存库的索引结构要放弃 B+ 树、转向更紧凑的结构
3. 对比 RDB 与 AOF 两条持久化路径的生成方式、恢复速度与丢失窗口
4. 说清内存库的三大代价：内存成本、容量上限、持久化拖累
5. 判断一个业务适合纯缓存、还是需要带持久化的内存库

一、内存为什么突然够用了

很多年以前，内存是稀缺品，一台服务器的内存可能还没有现在一部手机大。那时候数据库设计的默认假设是"内存很贵、磁盘很慢但便宜"，所以数据落磁盘，内存只做一层薄薄的缓存。为了在这个假设下榨出性能，才有了 B+ 树、缓冲池、预读、LRU 淘汰这些我们前面反复讲的东西——它们本质上都是在替磁盘这个慢角色打掩护。

但这个假设在最近十年被硬件的进步悄悄推翻了。服务器的标配内存从几十 GB 涨到了几百 GB，单机 TB 级内存已经不是新闻；同时内存的单位成本一路往下走，一台机器上能塞下的"热数据"越来越多。当你的整个业务数据都装得进内存时，一个念头就自然冒出来了：为什么不干脆把数据全放内存里，让磁盘滚出主路径？

内存数据库就是把这个念头做成了产品。它和"给传统库加内存缓存"是两回事。加缓存只是把访问最频繁的一小块数据提前放内存里，落盘、索引、事务这些主逻辑还是围着磁盘转；内存库则是把内存当唯一的一级存储，磁盘只负责在断电时兜底。两者表面上都在用内存，底层的设计哲学完全不同。

以 Redis 为例，它常被当成"缓存"，但它的数据结构、命令模型、持久化机制，全是按"数据就住在内存里"这个前提设计的。理解了这个前提，你才能理解它为什么快，以及它为什么在有些场景会丢数据。

同样是内存库，Memcached 和 Redis 代表了两种取向。Memcached 是纯缓存，数据丢了就丢了，重启从零开始，所以它做得极简、极快；Redis 多了持久化和丰富的数据结构，除了当缓存，还能当计数器、队列、会话存储，代价是复杂度和资源开销都上去了。选哪个，取决于你愿不愿意为"重启不丢"买单。

二、快从哪来：数据结构的重写

内存库的快，第一层来自"不做磁盘该做的事"。它没有缓冲池、没有页置换、没有把数据页从磁盘读进内存再解码这一整套流程。一条读请求的路径被压缩到最短：定位到内存地址，取出来，返回。省掉的每一步，都是磁盘时代的惯性动作。

第二层来自数据结构的重写。B+ 树是为磁盘设计的，它把节点做得跟磁盘页一样大，为的是减少寻道次数；但到了内存里，节点里的指针跳转反而成了负担——一次跳转就可能是一次缓存未命中。所以内存库改用更紧凑、更缓存友好的结构。

Redis 里最典型的是跳跃表和压缩列表。跳跃表是一种概率平衡的多层链表，查询一个有序键的时间复杂度和对数级相当，但它的节点小、局部性好，更新时不需要像红黑树那样做旋转。压缩列表则更极端，把多个小元素挤在一段连续内存里，用变长编码省空间，适合元素多但单个值小的场景。这些结构的一个共同点是：它们把"形状"和 CPU 缓存行对齐，让每一次内存访问都尽量带出有用的信息，而不是像 B+ 树那样为了填满一个磁盘页而塞进冗余。

第三层来自并发模型的简化。Redis 很长时间里是单线程执行命令，靠 I/O 多路复用同时监听大量连接。单线程听起来反直觉——多核不是更快吗？但对内存库来说，单线程换来了两样东西：一是完全不用加锁，省掉了锁竞争和死锁的整片泥潭；二是每个命令天然原子，事务语义简单得多。Redis 6 之后虽然引入了 I/O 多线程，但也只用来做网络读写，命令执行仍然是单线程串行的。这个取舍很关键：它承认瓶颈在网络收发而不是数据访问，所以把并发用在了刀刃上。

除了 Redis 这类键值内存库，还有一类把关系型 SQL 搬进内存的企业级系统，比如 SQL Server 的内存优化表、Oracle 的 TimesTen。它们的目标不是缓存，而是让完整的事务处理也吃到内存的低延迟。代价是必须自己解决持久化和崩溃恢复，所以往往比 Redis 重得多。

一句话：内存库的快，不是"更努力地做旧事"，而是把磁盘时代的一整层惯性动作直接删掉了。

三、持久化：Redis 的两条路

内存是易失的，一断电数据就没了。所以"内存为一级存储"这句话，必须补上后半句：磁盘仍然要承担备份，只是不再站在主路径上。Redis 给出了两条持久化路径，各有各的代价。

第一条路叫 RDB，全量快照。它定期把内存里的数据整体写成一份紧凑的二进制文件。实现上用的是 fork 一个子进程，靠操作系统的写时复制，让子进程拿到那一刻内存的稳定视图，主进程继续服务。RDB 的好处是文件小、恢复快，加载时整份读进来就行；坏处是两次快照之间如果崩了，这中间的数据就丢了。它的丢失窗口，等于快照的间隔时间。

第二条路叫 AOF，追加日志。它把每一条写命令按顺序追加到一个日志文件里，恢复时从头到尾重放一遍。AOF 可以配置刷盘策略：每次命令都刷，最安全也最慢；每秒刷一次，折中；交给操作系统，最快但丢得最多。AOF 的好处是丢失窗口小，坏处是文件会越滚越大、恢复比 RDB 慢。于是又有了 AOF 重写，定期把日志里那些"先写后删、写来写去"的命令合并成最终状态的等价命令，把文件压小。

两条路还能合在一起用。Redis 4 之后支持混合持久化：重写 AOF 时，先写一份 RDB 快照作为基底，再在后面追加增量命令。这样既有 RDB 的恢复速度，又有 AOF 的小丢失窗口。下面这张表把两条路径摊开对比。

⚠️ 常见坑：RDB 的 fork 并不是免费的。写时复制意味着，子进程快照期间，主进程一旦大量写，就会触发整页复制，内存占用可能瞬间翻倍。内存本来就很贵，这个坑在生产上经常被低估。

💡 关键直觉：持久化策略的本质是"丢多少数据换多少性能"。RDB 丢得多、恢复快；AOF 丢得少、恢复慢。没有哪个更好，只有你的业务能容忍多大的丢失窗口。

四、代价与坑：内存很贵，也很脆

内存库的第一个代价是成本。内存的单位价格比磁盘贵一个数量级以上，同样的钱，内存只能装下磁盘容量的零头。这意味着内存库天生装不下"全量历史数据"，只能装热数据，冷数据还得外溢到磁盘或者别的库里。这也是为什么很多内存库会和磁盘库组队：内存库扛热查询，磁盘库存全量。

第二个代价是容量上限。单机内存再大也有顶，一旦数据超过单机容量，就得做分片集群。而内存库分片之后，跨分片操作、集群一致性、节点扩缩容这些分布式难题一个都跑不掉。Redis 集群在键的哈希槽分布上做了简化，代价是跨槽的事务和聚合操作受限。

第三个代价是故障窗口。哪怕做了持久化，内存库在"最后一次落盘"到"崩溃"之间，始终有一个窗口会丢数据。对缓存场景，这无所谓，丢了重算；对把内存库当主库用的场景，这就是实打实的数据损失。所以我的建议是：内存库适合做缓存、计数器、会话、排行榜、消息队列这类"丢了能重建或能容忍"的数据，别把它当成唯一的事实源去存订单、账户余额这类不能丢的东西。

还有一个容易被忽略的点：内存库的持久化动作本身会拖累性能。RDB 的 fork 会抖动，AOF 的刷盘会阻塞，重写会抢 I/O。一个内存库声称的"十万级吞吐"，往往是在关闭持久化或者宽松刷盘策略下测出来的。选型时要把持久化的真实开销算进去，而不是只看宣传数字。

实际工程里，最常见的做法不是二选一，而是内存库加磁盘库组队：写请求先落磁盘主库保证不丢，再异步刷进 Redis 提供高速读。这个组合的难点在双写一致性——两边数据会有一个短暂的不一致窗口，需要靠过期时间、消息队列或者读写分离策略去兜底。想清楚这个窗口多大、能不能接受，比纠结用哪个内存库更重要。

核心回顾

• 一级存储：内存库把内存当唯一的一级存储，磁盘只做备份，这是它和"加缓存"的本质区别。
• 数据结构重写：用跳跃表、压缩列表等紧凑结构替代 B+ 树，把形状对齐到 CPU 缓存行。
• 单线程免锁：Redis 靠单线程串行执行命令换掉锁，Redis 6 的 I/O 多线程只做网络收发。
• RDB 快照：fork 子进程加写时复制，文件小、恢复快，但丢失窗口等于快照间隔。
• AOF 日志：追加写命令，丢失窗口小，但文件大、恢复慢，需要重写压缩。
• 混合持久化：重写时用快照打底、增量追加，兼顾恢复速度和丢失窗口。
• 选型边界：内存库适合能容忍丢失、能重建的数据，别当唯一事实源；持久化开销要算进真实性能。

内存库解决了"快"的问题，专门化存储要解决的是另一个问题：当数据长得不一样时，通用引擎的"快"和"对"都够不着。下一节我们看向量、时序、图、搜索这四类专卖店各自怎么把一种数据形态伺候到极致。