固定集合这个名字听起来像是 MongoDB 新手阶段练手才会碰的东西但我个人觉得它恰恰是很多后端老手也会忽略的宝藏特性。最早我是做访问日志模块时真正领会到它的价值一天上千万条日志全量保存不可能定期清理又会让普通集合的存储碎片越来越难看而固定集合capped collection天然就是为这种场景准备的——集合有容量上限写满后自动覆盖最早的数据像一个环形缓冲池不需要你手动删除任何东西。这篇文章我就把固定集合从原理、创建、容量计算、实战游标到踩坑经验一次性讲透适合做日志、消息缓存、埋点、最近N条记录这类功能的后端开发、运维和架构师参考。1. 固定集合是什么为什么需要它1.1 环形缓冲区的数据库版本固定集合从名字也能猜个大概这个集合有一个“固定”的容量上限一旦你创建时设定了size或者max它就只在这个范围内工作。写入新文档时如果容量还没满就正常追加如果已经满了就把最老的那批文档直接覆盖掉。这种机制你可以理解为操作系统里的环形缓冲区指针转一圈回到起点继续写旧数据自然被冲掉。这里有一个关键点固定集合的写入顺序是确定的。普通集合里文档的物理存放顺序和逻辑顺序没有必然关系查询时如果不带sort你得到的结果顺序不一定等于插入顺序。但固定集合不一样它维护了清晰的“自然顺序”也就是文档写入的顺序。默认查询返回的是从旧到新配合$natural排序可以直接拿到正向或反向的插入顺序。也正因为如此固定集合不太适合当成什么“高级存储”来用它更适合承载那些“有保质期”的数据日志、事件流、最近访问记录、待消费的任务列表。这个定位从 MongoDB 内部也能看出来——复制功能依赖的 oplog 本身就是固定集合官方自己都在用这个特性做“只保留最近变更记录”的引擎。1.2 和普通集合加手动清理相比省在哪里很多人在没接触固定集合之前处理“只留最近N条”这件事通常是这么干的正常往普通集合里写然后写一个定时任务定期把老数据删掉。看起来没什么问题但实际跑一段时间你就会发现几个痛点。第一删除是有代价的。普通集合的删除操作走的是正常的增删改查路径删除的文档越多对索引的维护压力越大写并发高的时候删除任务本身还会和业务请求抢资源。第二空间碎片很难看。删掉一批文档后集合在磁盘上留出的“洞”未必能被新写入充分利用集合文件越涨越大用compact之类的命令又得挑低峰期操作。第三删除的时机不好把控。删除频率太低磁盘容易被打满删除频率太高又浪费性能。固定集合把这些事情全压在写入路径上解决满了就在原地覆盖最老的数据不需要额外的定时任务也不需要关心碎片的回收。1.3 和 TTL 索引的差异别选错方案MongoDB 里还有一个和固定集合功能很像的机制TTL 索引。它允许你给某个时间字段建索引到期后后台线程自动删除过期文档。很多人问既然有 TTL还要固定集合干什么TTL 的核心是“按时间过期”它的清理动作由后台线程周期执行一般每 60 秒跑一次这就意味着文档的实际存活时间会超出你设定的时间而且这个偏差在数据量大时可能更明显。TTL 适合的是那些“每条数据有自己的过期时间”的场景比如验证码、临时 token、七天内的购物车记录。固定集合的核心是“按容量或条数滚动淘汰”它不管文档本身的时间戳只关心集合有没有装满。所以你要是想“始终保留最近 100 万条订单流水”或者“日志最多占 5GB 磁盘”固定集合比武断的 TTL 更合适。两者不冲突甚至可以组合使用固定集合里再配一个普通索引支持按时间查询效果也不错。2. 创建与容量管理语法、命令和常见误区2.1 从空集合开始创建固定集合固定集合不能用普通方式第一次写入时隐式创建必须显式调用createCollection因为你要告诉 MongoDB 它的容量是多少。基本语法是db.createCollection(audit_log, { capped: true, size: 5368709120, // 5GB单位是字节 max: 2000000 // 最多 200 万条可选 });size是固定集合的总容量字节数max是最多文档条数。这两个参数不是必须同时出现但我的建议是size一定要给max按需给。很多人只写了max而忘记size结果 MongoDB 在部分版本上会给一个非常小的默认容量你的集合可能没写几条就开始覆盖了表现就像“数据莫名其妙丢失”。固定集合的容量一旦定下来业务写入就受它硬约束所以这个值得在一开始就认真算清楚。另外如果你是在副本集或分片集群里操作createCollection这条命令可以写在主节点上它会通过复制同步到从节点。集合创建完之后最好立刻用db.audit_log.stats()确认一下capped: true已经生效。2.2 把已有普通集合转换为固定集合如果项目已经跑了很久数据都在普通集合里你不想停机重建可以用convertToCapped命令做在线转换db.runCommand({ convertToCapped: audit_log, size: 5368709120, max: 2000000 });这个命令会把一个普通集合复制并重建成固定集合。需要注意它不是瞬间完成的数据量越大花费的时间和占用的 IO 就越多尤其是集合里已经攒了几十 GB 数据时执行期间对业务写入会有明显影响。我的实战经验是转换操作务必放在低峰期并且先找一个从节点或者测试环境试跑一遍。如果你只是想调整一个已经存在的固定集合容量最稳妥的办法不是去赌某个隐蔽的collMod参数而是新建一个容量更大的固定集合把数据迁移过去再让业务流量切换。生产环境里少用花哨命令多走“新老替换”这种朴素但可靠的流程。2.3 容量相关的偏移量思维还有一点容易被忽略size是“总容量”但它并不完全等于“文档体积之和”。MongoDB 内部在存储引擎层面会有很多额外开销比如文档对齐、填充因子、索引空间。WiredTiger 引擎下固定集合一开始也不会真的把所有size空间都预分配到磁盘上storageSize会随着写入增长缓慢接近maxSize。这意味着你不能拿业务文档的平均大小直接乘以条数来估算空间得留出至少 20% 到 50% 的余量。db.audit_log.stats()你可以从输出里看几个关键字段capped表示是不是固定集合maxSize是创建时设定的容量上限size是当前所有文档身体积的总和storageSize是磁盘上实际占用的空间max是文档条数上限。如果storageSize已经非常接近maxSize说明这个集合已经处在持续覆盖边缘很快就要开始滚动淘汰旧数据了。3. 读写规则与使用边界哪些操作能踩雷3.1 自然顺序、索引与查询固定集合最舒服的一点是不需要额外担心查询顺序。普通集合里做“取最新几条”通常要依赖_id倒序或者时间字段倒序而固定集合可以直接这样写// 从旧到新 db.audit_log.find().sort({ $natural: 1 }); // 从新到旧业务上更常用 db.audit_log.find().sort({ $natural: -1 });$natural就是物理存储顺序的意思固定集合里它接近插入顺序。不过要注意这只是“接近”不是绝对保证。比如你在更新文档后文档位置相对移动了$natural的顺序可能就不再是严格的插入先后。所以不要把固定集合当成强顺序的消息队列来设计它更适合“最近的数据大概率在末尾”这种弱顺序场景。索引在固定集合上是可以建的。因为固定集合会不断覆盖老数据索引的体积也不会无限膨胀这对写日志这种高频写场景很有帮助。但有一个老毛病要提一下固定集合对唯一索引的支持一直不让人省心很多版本直接禁止在 capped collection 上创建唯一索引。我在生产里一般默认不依赖它业务唯一性靠_id兜底复杂唯一约束就让给普通集合去承担。3.2 文档更新、删除和分片限制固定集合的写路径是为追加设计的这就带来了一系列边界。最常踩的坑是更新如果更新导致文档体积变大在很长一段 MongoDB 版本里会直接报错错误信息类似cannot change the size of a document in a capped collection。即使新版引擎在某些条件下更包容你也别把固定集合当成普通业务表来用尤其是不要push数组、不要往里塞持续增长的大字段。保持文档大小相对稳定是固定集合健康运行的基本原则。删除也不一样。固定集合的设计目标就是“老数据被自动覆盖”所以从早期版本开始官方对这种集合的单条文档手动删除支持一直很弱。你要清空一个固定集合最干净的做法通常是直接drop整个集合后重建而不是写脚本一条条删。我见过不少新人上线前把固定集合当成普通日志表来设计“清理任务”结果跑出各种灵异问题。如果你预计业务需要频繁单条删除请重新考虑要不要用普通集合。分片也是个硬边界固定集合不能参与分片。想横向扩展写入能力又惦记着滚动淘汰功能这种组合在 MongoDB 里基本是不存在的。遇到这种需求老老实实改成普通集合外加按时间分区或者自定义滚动表方案。4. Tailable 游标把固定集合变成轻量消息队列4.1 为什么固定集合天生适合做队列固定集合最吸引人的衍生能力就是 Tailable 游标也就是“可尾随游标”。你可以理解成在终端里tail -f一个日志文件游标会一直盯住集合的末尾有新数据写入就立刻读出来没有新数据时它就睡在那里等而不是直接结束。这个能力配合固定集合“老数据自动覆盖”的特性非常适合做轻量级消息队列、埋点管道和事件流。MongoDB 自己的 oplog 就是固定集合副本集的同步进程本质上是拿着一个 Tailable 游标在追 oplog 的尾部。这也是为什么我一直建议想理解这个特性的朋友先去看看 oplog 的工作方式你就会意识到固定集合不是玩具它支撑着整个 MongoDB 的复制机制。4.2 用 PyMongo 写一个可跑通的消息消费端假设你有一个task_queue固定集合我直接用 PyMongo 写一个最简单的消费者import time from pymongo import MongoClient, CursorType client MongoClient(mongodb://127.0.0.1:27017) db client[demo] coll db[task_queue] while True: cursor coll.find( {}, cursor_typeCursorType.TAILABLE_AWAIT, await_dataTrue, ) while cursor.alive: try: doc next(cursor) handle(doc) # 你的业务处理逻辑 except StopIteration: # 暂时没有新数据等一会继续 time.sleep(0.2) time.sleep(1)核心就两点CursorType.TAILABLE_AWAIT让游标具备“没数据时等待新数据”的能力await_data告诉服务端在暂时没有数据时不要马上返回空结果而是稍微等一会儿再有新数据时返回。这样消费端就不需要反复轮询整个集合也不太容易漏掉写入间隙的数据对于单机内部的轻量任务分发完全够用。4.3 Tailable 游标和真正的消息队列差异不过要清醒一点这不是 Kafka也不是 RabbitMQ。固定集合里的消息被消费后并不会被标记为“已消费”所谓队列语义是靠cursor自己记住读取位置实现的。如果消费者挂了重连它只能从头开始读还没被覆盖的数据也就是说有可能重复消费而一旦容量满老消息又会被直接丢弃你做不到“确认消费”和“精确一次”。所以固定集合适合的是那些“丢了拉倒”或者“重复处理无所谓”的场景比如打点上报、缓存构建、内部任务通知。一旦牵扯到事务性消息、严格 ack、多消费者组并发消费请直接上专业消息中间件别拿 MongoDB 硬顶着当一个高可用队列。还有一点Tailable 游标在现代驱动里的行为有细微差异生产使用前务必把“游标耗尽后重新拉取”的逻辑处理干净否则消费者可能静默退出。5. 容量设计别凭感觉填 size5.1 一套可以抄走的估算方法很多人建固定集合时size都是拍脑袋给的先给 1GB跑几天发现满了加一倍。这么做也不是不行但更好的方式是提前用公式推一遍。一般流程是这样先算平均单条文档大小在 Mongo Shell 里可以用Object.bsonsize(doc)拿到某条文档的真实字节数再算保留窗口内需要容纳多少条比如业务是每天 500 万条日志你想保留 30 分钟那就是约 10 万条最后乘以文档大小再留 30% 到 50% 的存储引擎开销得到的就是size建议值。举个例子接口每秒产生 500 条日志平均每条 2KB要保留 1 小时。计算如下500 × 3600 × 2048 3,686,400,000字节约 3.44GB。按 1.4 倍补上存储引擎和索引的额外开销大概 4.8GBsize直接取 5GB 是合理的。如果产品允许丢一点数据可以适当缩到 3GB但代价是高峰期可能快速滚动覆盖。5.2 用 stats 动态监控滚动边界容量设计完不是万事大吉还得监控。我自己的做法是给固定集合写一个定时巡检脚本每隔几小时看一次db.collection.stats()里的maxSize和storageSize。当storageSize稳定在maxSize的 95% 以上时说明这个集合已经进入正常覆盖状态你的容量上限和业务量是匹配的。如果storageSize长期只有maxSize的一小半说明容量给大了可以考虑缩减反过来如果刚上线几小时就冲到 100%说明要么容量给小了要么文档平均大小远超预期需要立刻排查。5.3 扩容的正确姿势固定集合的容量一旦创建理论上就该稳定但业务发展总有需要扩容的时候。我见过有朋友尝试直接在原集合上修改配置结果不同版本的 MongoDB 对这个操作的支持完全不一样低版本直接不认。最稳的流程是新建一个容量更大的固定集合比如audit_log_v2然后在业务代码里做一次短暂的双写或者切换再把老集合drop掉。整个切换过程里数据会有少量丢失所以固定集合的容量规划为什么要在上线前认真做原因就在这——它天然不保证“历史全量”你需要的是把丢失窗口控制在可接受范围。6. 常见问题与排查技巧实录6.1 问题速查表我把这些年实际踩过的和同行问过的问题整理成一个速查表排查时可以对照着看。现象可能原因处理建议集合里数据条数远小于预期size太小老数据已经被滚动覆盖检查stats()中storageSize是否接近maxSize按业务需要扩容更新文档报大小错误更新后文档体积增大触碰固定集合限制保持文档大小稳定避免$push无界数组必要时改用普通集合单条记录删不掉固定集合对按文档删除支持很弱清空用drop重建设计上不要依赖单条删除创建唯一索引失败固定集合对唯一索引支持有限用_id保证唯一性复杂唯一约束放普通集合想分片但固定集合不配合固定集合不能分片改用普通集合 时间分片/滚动表方案Tailable 游标消费端静默退出游标耗尽后没有重新拉取在循环里处理StopIteration拉取姿势要重新建立游标convertToCapped执行期间业务卡顿命令会复制全量文档低峰期执行并把业务流量降级或切换6.2 避坑清单最后整理几条我从实战里沉淀下来的原则。第一条固定集合不要存放不可再生的核心业务数据它本质是一个缓冲池不是保险箱。第二条容量规划宁大勿小因为扩容比创建麻烦得多但也不要大到没有意义那会浪费磁盘。第三条设计时把“数据会被覆盖”写进业务预期而不是等线上真的丢数据了再惊讶。第四条能用 Tailable 游标消费就别写高频轮询轮询会放大集合压力游标才是匹配固定集合生产力的用法。第五条所有固定集合相关的索引、更新、删除行为都要在目标 MongoDB 版本上先用测试数据跑一遍因为版本之间的行为差异真的存在。我自己现在的习惯是固定集合上线前先灌一倍容量预估量的测试数据进去观察滚动覆盖的临界行为、storageSize增长曲线以及 Tailable 游标在“空转—有新数据—覆盖老数据”几种状态下的表现。这一套动作花不了多长时间但能帮你躲开很多“数据看起来丢了几条”的线上事故。固定集合没多复杂搞清楚它的能力边界它就是 MongoDB 里最顺手的日志和队列小工具。