企业官网建设流程全解析

搞后端的人一旦上了 MongoDB，最容易被默认配置坑一把的，就是没真正理解它那套缓存机制是怎么跑的。MongoDB 缓存机制并不神秘，WiredTiger 存储引擎里的 Cache 就是所有读写路径上的中继站；但如果你只会盯着内存占用看，不知道pages requested和pages read from disk之间的关系，构建高性能 NoSQL 数据缓存体系就只能是纸上谈兵。这篇文章我结合线上压测和事故复盘，把 Mongo 缓存机制的内部逻辑、多级缓存架构、一致性保障、参数调优和排障方法一次性说清楚。适合正在做 Mongo 性能调优的后端开发者、DBA，以及想把热点请求从数据库上彻底卸下来的架构同学。

1. 先搞明白：MongoDB 的"自带缓存"到底是什么

1.1 WiredTiger 缓存的核心逻辑：一切读写都绕不开它

MongoDB 从 3.2 开始默认使用 WiredTiger 存储引擎，这个引擎最核心的东西就是一个内存 Cache。它不缓存你理解的"一条 JSON 文档"，而是把磁盘上的数据页和索引页按页加载到内存里，所有读写操作都会先和这个页缓存打交道。

举个例子：你执行一条db.users.find({_id: 123})，如果对应文档所在的页已经在 Cache 中，MongoDB 直接返回内存数据，整个过程不碰磁盘；如果不在，WiredTiger 会从磁盘读到对应页，放入 Cache，再返回结果。这个机制和 Redis 这类纯缓存系统完全不同，Redis 缓存的是完整对象，而 WiredTiger 缓存的是存储引擎层面的"数据页块"。

这里有个关键点：WiredTiger 的 Cache 还承担写入缓冲。客户端写入文档时，数据先进入 Cache 并标记为脏页，后续由后台线程异步刷盘，同时写入 Journal 日志保证崩溃恢复。也就是说，Cache 不只是读加速，它还决定了写入的吞吐上限。如果 Cache 太小，频繁刷盘就会拖慢写入；如果 Cache 太大，淘汰和脏页管理又会带来额外的 CPU 开销。

明白了这个逻辑，你就能理解为什么很多人说"MongoDB 自带缓存，不需要额外加 Redis"。这句话只对了一半：小规模应用、单机读写、数据量远小于内存时，WiredTiger 的页缓存确实能让读性能非常接近内存级。但一旦数据量超过内存、出现热点集中的多实例场景，或者你需要对跨节点的缓存做统一管理，仅靠存储引擎自带的缓存远远不够。

1.2 缓存命中率应该怎么算：别被表面数字骗了

很多人用mongostat看hit rate之类的字段，其实比较靠谱的命中率计算方式要借助serverStatus()：

db.serverStatus().wiredTiger.cache

重点关注这几个指标：

• pages requested：客户端请求访问的总页数；
• pages read into cache：从磁盘读取到缓存的总页数；
• pages written from cache：从缓存写入磁盘的总页数。

引擎级读命中率的简化公式为：

命中率 = 1 - (pages read into cache / pages requested)

举个例子：假如线上实例某个时间段pages requested是 10,000,000，pages read into cache是 300,000，那引擎级命中率就是 97%。这个数字说明大部分读操作都命中了内存页，磁盘 IO 压力很小。

但你要注意，应用层的缓存命中率和引擎层的命中率是两回事。应用层如果加了 Redis，请求根本没到 MongoDB，引擎层感知不到这些请求，它的命中率自然也不能反映整体链路。所以实际做监控时，两个层面的命中率都要关注：引擎层命中率低了，说明数据库磁盘 IO 变多；应用层命中率低了，说明 Redis 或本地缓存的覆盖不够。

1.3 cacheSizeGB 的默认值逻辑与常见误区

WiredTiger Cache 的大小由storage.wiredTiger.engineConfig.cacheSizeGB控制。很多人不知道，默认值是(总内存 - 1) / 2，下限 1GB。比如服务器总内存 64GB，默认 Cache 就是 31.5GB。

这个默认值设计得很保守，因为 MongoDB 进程的内存占用不只有 Cache，还有连接池、排序缓冲、聚合管道、索引构建等。如果服务器上只跑一个 mongod，把cacheSizeGB调高到总内存的 60%~70% 通常能明显提升读性能。但如果服务器上还跑着应用、监控 Agent、其他数据库，直接按默认或拍脑袋调大，很容易触发操作系统内存回收和 OOM。

我踩过一个大坑：某个模拟项目把 32GB 机器上的 cacheSizeGB 调到 28GB，以为能提升缓存命中率，结果 mongod 跑了一段时间后内存持续上涨，操作系统开始大量 swap，整个集群响应变得极慢。后来把 cacheSizeGB 降到 18GB，同时给系统预留足够的页缓存空间，问题才解决。

注意：这里有个容易误解的点——cacheSizeGB限制的是 WiredTiger 页缓存的体积，并不是 mongod 全部内存。mongod 还有连接内存、排序内存等其他部分。所以调优时要看 mongod 进程的 RSS，而不是只盯着 cacheSizeGB。

2. 高性能缓存体系：从单机页缓存到多级缓存架构

2.1 三层缓存架构：本地缓存 + Redis + MongoDB

如果你面对的是高 QPS 的读多写少业务，只靠 WiredTiger 的页缓存硬扛迟早出事。我建议的通用架构是三层：

第一层：应用进程内本地缓存。用 Caffeine 或 Guava Cache 这类进程内缓存，承接最高频的重复查询。这一层延迟最低，零网络开销，但缺点是每个应用实例各存一份，数据一致性弱。

第二层：集中式 Redis 缓存。承接跨实例的共享热数据，解决多个应用节点之间的缓存不一致问题，同时减轻 MongoDB 的压力。

第三层：MongoDB 自身的页缓存。作为最终兜底，处理未命中 Redis 的读请求，以及所有写请求。

举个例子：一个订单详情接口，QPS 峰值为 2 万。第一次请求到达时，本地缓存没有，Redis 没有，最终打向 MongoDB，生成订单详情 JSON 后写入 Redis（TTL 5 分钟），应用本地缓存（TTL 30 秒）。后续请求中，30 秒内约 80% 的流量直接命中本地缓存，20% 的流量打到 Redis，只有极少量穿透到 MongoDB。

这个分层设计的关键是 TTL 错开：本地缓存短、Redis 缓存长。这样即使所有应用实例的本地缓存同时过期，Redis 还能挡住大部分并发，MongoDB 不会被瞬时击穿。

2.2 为什么不能只依赖 Redis 一层

有的团队图省事，把所有缓存逻辑都放到 Redis，应用不设本地缓存。表面上实现简单，实际并发一高就有问题：Redis 的网络开销虽然比查 MongoDB 小得多，但面对几万 QPS 的热点 key，Redis 单实例也会成为瓶颈。即使 Redis 集群能扛，MongoDB 与 Redis 之间的数据同步、序列化开销也不小。

更重要的是，本地缓存能消化掉大量重复请求，这些请求如果全部打到 Redis，会造成不必要的网络和 CPU 浪费。举个例子，某接口被同一个用户连续调用 10 次，如果没有本地缓存，这 10 次请求全部需要网络往返 Redis。有了本地缓存，第二次到第十次直接在应用进程内返回，耗时从毫秒级降到微秒级。

当然，本地缓存也有代价，最大的问题就是多实例一致性问题。A 实例更新了一条数据，B 实例的本地缓存还是老版本。所以本地缓存只适合放那些对短暂不一致容忍度高的数据，比如商品名称、用户昵称、配置项；订单状态这类强一致数据，尽量走 Redis 或直接查 MongoDB。

2.3 缓存粒度与 Key 设计：没有合理粒度，一切缓存都是空谈

缓存粒度决定了缓存命中率的上限。我见过很多团队把所有数据一股脑按"整表缓存"处理，结果数据一更新，整块缓存全部失效，命中率惨不忍睹。

常规的做法是按访问模式拆分成三档：

实体级缓存。比如product:123:detail:v2缓存单个商品的详情，更新商品时精确失效这一个 key，影响范围最小。

列表级缓存。比如user:456:orders:page:1:status:paid缓存某用户第一页已支付订单。问题在于用户新下一单后，列表顺序会变，你需要把该用户所有订单列表 key 全部失效。

聚合查询缓存。比如统计报表、排行榜，缓存 key 带版本号或日期段，如rank:2024-06-01。这类缓存更新频率低，收益最大。

Key 设计上，我的经验是用"业务前缀 + 主键 + 场景标识 + 版本号"的方式。例如：

order:789123:detail:v3

带版本号的好处是，当数据结构或序列化方式变化时，不需要批量删除 Redis 里的旧 key，只要把查询代码里的版本号改成 v4，旧 key 自然过期，避免引发缓存雪崩。

注意：列表缓存最容易踩"缓存穿透 + 缓存雪崩"组合坑。用户订单列表如果缓存 key 太多，且分散在各个用户的维度下，你很难做统一的预热。更可行的方案是对列表页只缓存前几页，超过一定页数的查询直接查 MongoDB，因为深分页的流量占比极低，缓存收益不大。

3. 缓存一致性策略：更新与失效怎么设计才不踩坑

3.1 四种缓存更新模式对比

缓存体系搭建容易，一致性才是真正的分水岭。工程上常见的更新模式有四种：

MongoDB 场景下我最常用的还是Cache Aside + 主动删除。原因很简单：MongoDB 的文档模型天然适合"按主键更新一条文档"，更新后立刻删除对应缓存，比 Write Through 简单可靠，也不会像 Write Back 那样引入丢失数据的风险。

3.2 更新数据库后删除缓存失败怎么办

Cache Aside 最大的隐患是"更新数据库成功，删除缓存失败"。举个例子：用户支付成功后，订单状态从pending变成paid；如果支付服务更新完 MongoDB，紧接着删除 Redis key 时网络抖动失败，那接下来所有请求都会读到旧状态，用户明明付了钱，页面却还显示待支付。

解决这个问题的标准姿势是升级为"延迟双删"或者引入重试机制。

所谓延迟双删，指的是更新数据库后先删除一次缓存，隔几百毫秒再删除第二次。这样即使第一次删除失败，第二次也能兜底。更工程化的做法是：更新数据库后发送一条 MQ 消息，由消费端异步删除 Redis key；删除 action 重试 N 次，失败后进入死信队列人工处理。

还有一种比较优雅的兜底方案是利用 Mongo 的 Change Streams。监听订单集合的 update 操作，只要文档发生变化，就把变更事件发到队列，消费端统一失效相关缓存。这套方案的好处是缓存失效完全从业务代码中抽离出来，不会漏删。

伪代码思路如下：

// 监听 orders 集合的 change stream const changeStream = db.collection('orders').watch([ { $match: { operationType: { $in: ['update', 'replace', 'delete'] } } } ]); changeStream.on('change', (change) => { const orderId = change.documentKey._id; // 发送失效消息到 MQ 或 Redis Stream redisQueue.publish('cache.invalidate.order', `order:${orderId}:detail`); });

3.3 列表缓存失效：一张订单状态变更引发的连锁反应

订单场景里，一个核心问题：更新一条订单，需要失效多少 key？

假设订单状态从pending变成paid，缓存里可能有：

• order:123:detail:v3：订单详情；
• user:456:orders:page:1:status:pending：待支付列表；
• user:456:orders:page:1:status:paid：已支付列表；
• user:456:orders:page:2:all：全部订单列表。

如果你只删了详情 key，用户刷新订单列表时仍然看到旧的pending状态。所以更新一条核心业务对象时，要事先制定好"失效清单"，把该对象关联的列表缓存全部删掉。

实际工程中，这种级联失效逻辑很容易漏，我的做法是：为每个集合维护一张"缓存依赖表"，记录哪条业务数据会影响到哪些缓存 key 前缀。每次发版时拿着这张表对照审核，基本能把缓存一致性问题消灭在设计阶段。

还有一个更省心的思路：给列表缓存设计一个业务版本号。比如用户所有订单列表的 key 统一加上listVersion：

user:456:orders:list:v8:page:1:status:all

只要用户的订单发生变化，就把listVersion从小到大递增，旧 key 自然失效，而不需要遍历删除所有分页、状态组合的 key。这个技巧在数据量大的时候能省掉非常多的 Redis 删除开销。

4. 参数调优与监控告警：让缓存体系稳定运行

4.1 必须要盯的 WiredTiger Cache 指标

没有监控的调优都是盲人摸象。我在所有 MongoDB 实例上都会配置以下监控项，全部来自serverStatus()：

db.serverStatus().wiredTiger.cache

关键指标和解读：

命令行的简单观察方式是mongostat，关注dirty字段。如果dirty长期超过 20%，说明脏页比例偏高，后台刷盘线程可能跟不上写入速率。这种情况下，即使你加大了 cacheSizeGB，脏页也可能占用大量缓存空间，导致干净页被提前淘汰，读命中率反而下降。

4.2 调参实操：cacheSizeGB 到底怎么设置

cacheSizeGB的设置不是"越大越好"，而是"够用且不挤占系统"。

我常用的计算方法是：

cacheSizeGB = min(物理内存 * 0.6, 物理内存 - 系统预留 - 应用占用)

举个例子：A 实例是专用 MongoDB 服务器，64GB 内存，无其他应用。预留 4GB 给操作系统，再留 4GB 给 mongod 的连接和排序缓冲，cacheSizeGB 设置在 36~40GB 比较合理。B 实例是应用和 MongoDB 混部，应用占 24GB，物理内存 64GB，那 cacheSizeGB 设置在 20~24GB，留足系统缓冲，避免触发 swap。

修改方式有两种：

方式一：配置文件

storage: wiredTiger: engineConfig: cacheSizeGB: 36

方式二：启动参数

mongod --wiredTigerCacheSizeGB 36

注意：修改cacheSizeGB后需要重启 mongod 才能生效。如果线上实例不能随便重启，可以通过db.adminCommand({setParameter: 1, wiredTigerEngineRuntimeConfig: "cache_size=36G"})热调整部分参数，但 cache_size 在运行时调整的效果有限，建议还是规划维护窗口重启。

除了 cacheSizeGB，还有一个参数值得关注：eviction线程配置。如果淘汰压力大，可以调整 WiredTiger 的 eviction 线程数：

storage: wiredTiger: engineConfig: configString: "eviction=(threads_min=4,threads_max=8),eviction_dirty_target=15,eviction_dirty_trigger=25"

这个配置的意思是最小 4 个、最大 8 个淘汰线程，脏页占比达到 15% 开始后台淘汰，达到 25% 强制淘汰。对于写入密集的业务，适当提高 eviction 线程数能显著改善响应延迟。但注意，线程数不是越多越好，过多会抢占 CPU，影响正常读写。

4.3 缓存被大查询污染：这是最容易被忽视的隐形杀手

我处理过好几个"为什么缓存命中率突然从 95% 掉到 60%"的线上问题，最后排查下来都是同一个原因：某个聚合分析任务执行了全表扫描，把大量冷数据页加载进 WiredTiger Cache，把热点数据页挤出去了。

举个例子：业务正处在晚高峰，订单查询依赖的订单文档页本来都躺在缓存里。这时候后台跑了一个报表任务，扫了整张订单集合做统计，Cache 里立刻被几十万冷数据页填满，原本热点的订单页被淘汰，前台查询开始大量读磁盘，接口耗时瞬间翻倍。

解决这类问题的思路有三个：

一是给分析类查询强制走从节点，设置readPreference: secondary，让它不影响主节点缓存。

二是给大查询加限制，比如maxTimeMS、limit、projection，尽量避免把整行大字段读入缓存。

三是把分析任务放到业务低峰期执行，或者将数据导出到单独的统计分析实例。隔离分析查询和业务查询，是保护缓存体系最直接的手段。

4.4 副本集与分片集群的缓存差异

如果你的 MongoDB 是副本集或分片集群，缓存管理会更复杂一些。副本集每个节点都有独立的 WiredTiger Cache，主节点承担写入和大部分读，从节点如果通过readPreference=secondary分流读流量，从节点的缓存命中率就取决于它的读模式。

如果从节点一直被随机查询刷缓存，它的缓存会很不稳定。所以生产环境建议对从节点读做分类：可容忍延迟的分析读、备份读走从节点；对延迟敏感的核心业务读，尽量走主节点，保证主节点缓存的高命中率。

分片集群下，每个分片节点的缓存是独立的。一个跨分片的查询会被 mongos 拆分成多个分片查询，每个分片只缓存自己那部分数据。这就意味着，如果你有三个分片，每个分片 32GB 缓存，整个集群的页缓存总量是 96GB，而不是你以为的"一个 MongoDB 有 96GB 缓存"。扩容时，除了考虑分片数据均衡，还要考虑每个分片节点的内存容量是否能满足热数据缓存需求。

5. 常见问题与排查技巧实录

5.1 缓存命中率长期偏低怎么办

先按这个顺序排查：

1. 看pages read into cache增速。如果持续高增长，说明有大量磁盘读，检查是否存在全表扫描或缺少索引。
2. 看explain()执行计划，确认查询走了索引还是COLLSCAN。凡是COLLSCAN的查询，即使有缓存，它也会把大量无关页带进缓存。
3. 看 Cache 中数据组成。用db.serverStatus().wiredTiger.block-manager检查数据块读入情况，如果是分析任务污染，参考 4.3 的隔离方案。
4. 确认数据量与 cacheSizeGB 的比例。如果热数据超过缓存上限十倍以上，命中率自然低，这时候应该优化索引、裁剪字段、加 Redis 或增加节点。

5.2 dirty 比例长期偏高，写入性能上不去

dirty 比例长期高于 20%，通常意味着刷盘速度跟不上写入速度。排查方向：

• 检查磁盘类型和 IOPS，机械盘或低规格的云盘会成为刷盘瓶颈；
• 检查是否同时开启了大量索引，索引更新会放大写入负载；
• 检查写入并发是否过大，可以考虑适当限速，比如写队列积压时做背压；
• 调整eviction_dirty_target和eviction_dirty_trigger，让后台更早开始刷脏页。

我遇到过一次真实事故：某个实例大量批量更新用户字段，每次批量更新 2 万条文档，脏页瞬间飙升，几乎每秒都在触发强制淘汰，整个 mongod 的 CPU 和磁盘 IO 全部打满，查询全部超时。解决办法是把批量更新拆成每批 1000 条，每条间隔几十毫秒，让脏页有机会刷盘，整体吞吐不降反升，延迟恢复平稳。

5.3 缓存穿透、击穿与雪崩的 MongoDB 侧应对

这三个问题不只是 Redis 的专利，MongoDB 也会被拖下水。

穿透：查询一个不存在的 ID，Redis 没数据，MongoDB 也没有。如果攻击者高频请求不存在的 ID，MongoDB 会被无效查询拖垮。处理方式是：缓存空值（设置短 TTL），或者用布隆过滤器在前端拦截不存在的 key。

击穿：某个热点 key 刚好过期，大量请求同时打到 MongoDB。比如某个爆款商品详情缓存过期后，瞬间有 10 万请求涌入。MongoDB 页缓存即便有数据，也可能因为连接数暴增而出现 CPU 飙高。处理方式是：加互斥锁，重建缓存的请求只允许一个线程执行，其他线程等待锁释放后读取新缓存，这就是"单飞"模式。

雪崩：大量 key 同一时间过期。比如批量设置的 TTL 都是 3600 秒，一小时后全部过期，所有请求同时查库。处理方式是：TTL 加随机偏移，比如 3600 + random(0, 300)，让过期时间均匀分散。

5.4 从监控到告警：你至少需要这几个规则

根据我的排障经验，最少要配置这几条告警规则：

把这几个指标加进你的监控大盘，基本能避免大部分 MongoDB 缓存相关的线上事故。

我的个人实操体会

踩过这么多次坑之后，我的体会是：MongoDB 缓存体系不要一上来就堆组件。你先要做的永远是搞清楚 WiredTiger 页缓存的状态，把命中率、dirty 比例、淘汰压力这些基础指标监控起来。很多小业务其实不需要 Redis——只要索引建得对、cacheSizeGB 配得合理、分析查询不污染页缓存，MongoDB 自带缓存就能达到非常可观的性能。真正需要引入本地缓存和 Redis 的场景，是当你有多个应用实例需要共享热点数据、或者单机 CPU 已经因为查询优化无法再压榨的时候。

如果这篇文章对你有点用，我最想让你带走的一条经验是：先把缓存监控做起来，再去谈优化和架构调整。没有数据支撑的缓存调优，十次有八次是在自我感动。