企业官网建设流程全解析

前阵子有个朋友问我，说他们后端要做一个日志采集系统，数据量不算特别大，每天几个GB，主要用来排查线上问题、统计接口错误率。他第一反应是用 Elasticsearch，但又觉得运维成本高，问我有没有更轻量的方案。我当时跟他说：你们这个量级、这个查询需求，MongoDB 完全够用，而且能省掉一大半的运维复杂度。

后来我仔细想了想，这个场景其实非常典型。很多人一聊到日志系统，脑子里就是 ES + Kafka + Logstash 那一套全家桶，却忽略了 MongoDB 本身就是一套非常成熟的分布式数据库，有文档模型、有 TTL 索引、有复制集和分片，天生就适合做日志这类“写多读少、有时效性、查询条件固定”的数据。这篇文章就把我自己在项目里用 MongoDB 设计日志系统的完整思路讲一遍，从需求拆解到集合设计、写入优化、查询建模，再到生产环境里踩过的坑，一次性说清楚。

1. 日志系统的业务画像：先想清楚日志和普通业务数据的本质差别

我见过太多人上来就设计表结构、写接口，结果做到一半发现方向错了。日志系统跟普通业务系统最大的区别在于——你对日志数据的“态度”完全不一样。普通业务数据是资产，要长期保留、要保证准确；日志数据更像是“消耗品”，它有价值，但价值会快速衰减，而且它的价值密度极低，绝大部分日志永远不会被翻出来看。

1.1 日志数据的四个核心特征

先把日志的特征列一列，这决定了后面所有设计决策：

• 写多读少：日志几乎只在产生的瞬间被写入，写入后基本不会被修改。查询集中在最近一段时间，历史日志查的概率极低。
• 追加为主：日志是典型的 append-only 数据流，业务上不应该出现“修改一条日志”的需求。就算要修复，也应该是新写入一条日志，而不是 update 旧记录。
• 数据猛增：日志不需要像普通业务数据那样“珍惜空间”。一个接口一天调几百万次，就可能产生几百万条日志，增长速度远超业务数据。
• 生命周期有限：日志一般都有明确的保留期，比如 7 天、30 天、90 天。过期之后留着没有任何收益，只会白白占用存储和拖慢查询。

这四个特征放在一起，你会发现一个很扎心的事实：日志系统的核心难点不是“怎么存”，而是“怎么在数据快速增长的同时，保持查询可用，并且高效地删除老数据”。

1.2 为什么传统关系库在日志场景里容易受伤

如果拿 MySQL 这类关系型数据库来存日志，问题会集中出现在三个地方：

第一，表结构不够灵活。日志字段经常变，今天加个requestId，明天加个userId，关系库加列要迁移表，表大了之后一次 DDL 能让你心跳加速。第二，写入吞吐受限。关系库为了保证 ACID，写入路径上的事务、锁、索引更新开销都不小，单表写入很容易触到瓶颈。第三，历史数据清理麻烦。你要么写定时任务DELETE FROM log WHERE create_time < ...，删几百万条数据能把主库拖垮，要么做分区表，但分区表的运维复杂度又是另一笔账。

当然不是说 MySQL 完全不能做日志，小规模场景凑合用也行，但量级一上来就各种别扭。

1.3 MongoDB 在这个场景中的真实定位

MongoDB 的逻辑文档模型天然契合日志这种“字段不固定、频繁变化”的数据。你不需要预定义所有字段，来了什么存什么，后面加字段也完全不慌。TTL 索引更是为日志这种有时效性的数据量身定做的——它可以在数据库内部自动删除过期文档，不用你写定时任务、不用你操心删数据会不会影响业务。

还有一点被很多人忽视：MongoDB 的复制集和分片能力相当成熟。日志场景对一致性要求不高，可以放心用复制集做高可用，写入量大了还能分片扩展。从中小规模到大规模，中间不用换技术栈。

不过要声明一下，我这里说的是“业务日志”，比如应用日志、接口访问日志、操作审计日志这些。如果你要的是全文检索那种“在几十亿条日志里按关键字秒出结果”，那还是得认认真真用 ES，这不是 MongoDB 擅长的事。后面我会专门讲这个边界。

2. 存储结构设计：集合划分是第一道决定成败的分水岭

想清楚了日志的特性和适用场景，下一步就是落库结构。这是整个系统的地基，结构设计错了，后面想改成本非常高。我在设计时最关注三个点：用几个集合、每个集合里存什么、过期数据怎么清理。

2.1 单集合还是分集合：别拍脑袋，先算体量

最简单的做法是把所有日志放进一个集合里，然后靠 TTL 索引统一清理。这个方案在数据量可控时完全没问题，省心省力。但如果日志量很大，比如每天新增上亿条文档，单集合就会遇到几个麻烦：索引越来越大，内存快照压力高；后台的 TTL 删除线程可能跟不上写入速度导致数据积压；而且查询时扫描的索引范围变大，响应时间不稳定。

所以更稳妥的做法是按时间维度分集合，常见的有两种：按天分表（app_log_20250115）和按月分表（app_log_202501）。具体选哪个粒度，取决于你的单日体量和查询习惯。

举个例子，我参与过的某个项目中日志峰值写入在每秒 2000 条左右，每条日志大概 1KB，算下来一天数据量约 170GB，这就必须按天分表。按天分表之后，单个集合索引小、维护快、TTL 清理精准，查询某一天直接锁集合，不用在几十亿文档里大海捞针。如果数据量比较小，每天只有几十万条，按月分表就够了，管理起来更省事。

提示：分表粒度不要低于“天”。按小时分集合不是不行，但集合数量膨胀太快，后面管理成本会超过收益，我们后面讲坑的时候会展开。

2.2 字段设计的黄金组合：时间、追踪、维度、详情

不管怎么分集合，日志文档的字段设计是共通的。基于我自己的经验，一个合理的日志文档应该包含四类信息：

很多新手喜欢把level存成中文枚举值，比如“错误”“警告”，倒也能用，但建议还是用error、warn、info这样的英文短字符串。一方面数据量小，索引也小；另一方面查询时不用转义，聚合分组时也更利索。

另外关于_id字段，MongoDB 默认的 ObjectId 本身就包含时间信息（前 4 字节是时间戳），这在日志场景里有个好处：如果你不显式指定_id，按_id排序得到的顺序基本上就是写入顺序，查“最近 N 条日志”非常高效，不需要额外的排序索引。

2.3 TTL 索引：自动清理是神器，但别忽略它的机制

TTL 索引是 MongoDB 日志系统的灵魂。它的原理很简单：在某个日期类型字段上建一个特殊索引，MongoDB 后台会周期性地扫描这个索引，把超过指定时间的文档删掉。

db.app_log_20250115.createIndex( { timestamp: 1 }, { expireAfterSeconds: 604800 } // 7天 )

这个操作会在集合里生成一个 TTL 索引，expireAfterSeconds设成 604800 秒，也就是 7 天，那么文档里timestamp字段的值在 7 天之前的都会被自动删除。

这里有几个关键点你得清楚：

• TTL 索引建在哪个字段，删除就以哪个字段的时间为准。所以要确保timestamp字段存的是日志产生时间，而不是写入时间——两者相差几小时甚至几天的情况在异步写入时经常出现。
• TTL 的删除不是实时发生的。后台的 TTL Monitor 通常每 60 秒跑一次，也就是说日志到期之后最多一个小时左右会被清掉。这个延迟对绝大多数场景没有影响，但如果你有“过期日志必须立刻消失”的合规需求，就需要额外处理。
• 如果你用分表方案，TTL 索引可以在建表时就同步创建。这里有个小技巧：建表和建索引一起做，避免数据灌进来之后才想起来建索引，导致第一次写入时索引构建对性能的影响。

3. 写入链路的并发优化：让日志落库不拖累业务

日志系统面向的写入场景是持续的、高并发的。如果写入逻辑设计得不好，日志系统不仅发挥不了价值，还可能反向把业务接口拖慢。我在实践中的体会是，写入优化有三个层次：单个写入怎么发、批量写入怎么攒、峰值流量怎么扛。

3.1 写入确认级别：别为了追求速度牺牲可靠性

MongoDB 驱动写入时可以通过writeConcern控制确认级别，常见的有不用确认（w: 0）、主库确认（w: 1）和多数派确认（w: majority）。

日志场景我在大多数时候建议用w: 1，也就是主库写入成功就算成功。有些人为了追求极致写入速度，把writeConcern设成w: 0，客户端发完请求就不管了。我个人的经验是：除非你确实能容忍日志莫名其妙丢一部分，而且丢了也无所谓，否则别上w: 0。这个模式下，写入失败你是不知道的，哪天磁盘出问题、连接出问题，日志悄悄丢了，排查线上故障时你会非常痛苦。

那w: majority呢？如果日志要承担审计责任，或者业务上要求日志绝对不能丢，那就用。但需要接受写入延迟变高的事实。普通应用日志没必要这么重——主库挂了会自动切换，切换瞬间丢的几条日志，对排查问题几乎没有影响。

3.2 单条写还是批量写：量级差一个数量级

给 MongoDB 写日志最忌一条一条插入。同样 1 万条日志，单条insertOne循环插入和bulkWrite批量写入的性能差距能达到 5 到 10 倍。原因很简单：每条写入都要走一次网络往返和驱动封装的开销，批量写入只是把多条合并成一次。

批量写也不是越大越好。我测过的经验值，一批 100 到 500 条是比较理想的区间。太少，网络往返优势不明显；太多，单次请求内存开销变大，MongoDB 那边处理单个请求的时间也会变长，反而增加等待队列的耗时。

3.3 缓冲队列模式：吞吐稳定利器

为了把批量写入落实到位，我一般在应用层加一个简单的缓冲队列。核心思路是：日志先进内存队列，后台线程按“攒够 200 条”或“每 2 秒”——两个条件先满足哪个就触发——批量刷到 MongoDB。

let queue = [] let timer = null function logToMongo(doc) { queue.push(doc) if (queue.length >= 200) { flush() } else if (!timer) { timer = setTimeout(flush, 2000) } } function flush() { if (queue.length === 0) return const batch = queue queue = [] timer = null db.collection('app_log').bulkWrite(batch.map(item => ({ insertOne: { document: item } }))) }

这个模式的好处是：把业务线程的写入时间降到了微秒级（只是数组 push），真正的写入由后台线程批量做，业务接口完全不会被日志拖累。

但它有个代价：进程崩溃时，内存里没刷出去的那批日志会直接丢失。这是所有缓冲队列方案逃不掉的权衡。如果日志对完整性要求很高，可以把缓冲区改成持久化队列（比如先写本地文件，再异步同步到 MongoDB），但复杂度也会上一个台阶。就我自己而言，普通业务日志用内存缓冲足够，至于“减少丢失”这件事，更重要的其实是日志采集端和应用端的配合，后续有机会单独写一篇。

3.4 瞬时峰值的应对：从集合设计到接入端的退避

日志有个特点：流量是突发的。白天业务高峰期写入量是深夜的好几倍，搞活动的时候可能是平时的几十倍。要扛住这种峰值，光靠批量写还不够，还要做几个预防：

一是不要在生产环境对日志集合做任何阻塞性操作。比如compact、重建索引、批量导入导出，这些操作会争抢资源，你不想在流量最猛的时候因为维护动作把日志写入卡住。

二是接入端要做背压控制。如果 MongoDB 写入已经跟不上，客户端要能识别到写入失败或超时，然后进入降级模式，比如把日志先落到本地磁盘，而不是无限重试把下游打挂。这个点在实际项目中太常见了——日志系统在业务高峰期垮掉，结果反而丢了最需要的高峰日志。

4. 查询与分析能力的打造：日志不只是存下来，更要查得动

日志存下来不是目的，能快速查、能方便统计才是。日志的查询模式其实非常固定，就那么几类：查某个时间段内的日志、按级别或模块筛、按 traceId 串一次请求。设计索引和查询方式的时候，要针对这几个固定模式来优化。

4.1 索引设计的核心：把最常查的字段组合起来

日志查询最常见的条件组合是timestamp + level，就是“查某个时间范围内所有 error 日志”。这种查询最有效的索引是复合索引，关键问题是指字段顺序怎么排。

MongoDB 复合索引遵循一个基本原则：范围查询字段放后面，等值查询字段放前面。因为索引里如果一个字段走的是范围匹配，后面的字段就无法高效利用索引了。所以level放第一个字段，timestamp放第二个字段，效果最好：

db.app_log_20250115.createIndex( { level: 1, timestamp: 1 } )

这样查询“最近一小时内的 error 日志”时，MongoDB 先用level精确锁定文档子集，再在子集内按时间扫描，效率很高。反过来如果建{ timestamp: 1, level: 1 }，等值筛选level的条件就用不上索引的优势，范围内的扫描量会大得多。

如果你想支持traceId追踪，单值字段索引就够了。这个索引不需要放进复合索引里，因为 traceId 的查询一般是单独出现的，单独建索引更灵活。

4.2 聚合分析：巧用 MongoDB 的 MapReduce 替代品

日志系统除了查询，还经常要做统计，比如“最近 24 小时各接口的错误数”“按小时维度统计日志量趋势”。MongoDB 的聚合管道（Aggregation Pipeline）在这个场景非常好用，而且不需要额外引入其他数据处理组件。

db.app_log_20250115.aggregate([ { $match: { timestamp: { $gte: new Date(Date.now() - 3600 * 1000) }, level: 'error' } }, { $group: { _id: { $dateToString: { format: '%Y-%m-%d %H:00', date: '$timestamp' } }, count: { $sum: 1 } } }, { $sort: { _id: 1 } } ])

这段聚合表达式做的事情是：先过滤出最近一小时内 level 为 error 的日志，然后按小时分组统计数量，最后按时间排序输出。好处是整个过程在数据库内完成，不需要把数据传输到应用层再统计。

不过要注意，聚合管道在高并发下会占资源。如果统计任务比较重，建议定时任务跑，或者直接读从库跑聚合，避免影响写入。

4.3 全文检索的边界：别把 MongoDB 当 ES 用

这是日志系统设计里最容易走歪的地方。很多人上来就要“按关键字搜日志”，比如搜 message 里包含“NullPointerException”的所有日志。MongoDB 不是不能做这件事——它有正则表达式查询，也有 Atlas Search 这种全文搜索能力，但自建 MongoDB 情况下的正则查询，性能非常不理想，尤其是数据量大时，它会做全集合扫描或者索引扫描的代价极高。

我的建议是这样的：如果你的日志量在百万级以内，偶尔用一下{ message: /NullPointerException/ }做排查，问题不大；如果日志量到了亿级，还要频繁做关键字搜索，老老实实引入 Elasticsearch 做日志的二级索引，MongoDB 继续做原始数据的存储和 TTL 清理。这样两者各司其职，而不是把 MongoDB 逼到它不擅长的领域。

另外还有一个很多人没意识到的问题：日志查询一定要强制带时间范围。就算有索引，不带时间范围的日志查询也很容易触发大范围的索引扫描。我在团队里推行过一个做法，所有日志查询接口必须在参数里指定起止时间，且时间跨度不能超过 24 小时（后台导出可以有更大跨度），这条规则执行之后，查询慢的投诉直接少了一多半。

5. 集群架构与容灾设计：日志系统的可用性等级

日志系统虽然不像交易系统那样要求 99.99% 可用，但一旦挂了，恰恰是线上出问题的时候最需要它。所以一个靠谱的日志系统，高可用不能太寒酸。这一节讲清楚不同规模下的架构选型。

5.1 复制集：最低配置也至少要三个节点

MongoDB 的复制集是可用性的基石。一个复制集里有一个主节点（Primary）负责写，其他从节点（Secondary）负责同步数据，主节点挂了自动选举新主。

日志场景我建议最低配三节点：一个主节点、一个从节点、一个仲裁节点（或者两个从节点，看预算）。有的团队觉得“只有一个节点，定期自己备份就行了”，这种做法在日志量小、容忍停机时勉强能用，但一旦磁盘满了或者数据文件坏了，你会发现连个备用的能顶上来的都没有。

复制集还能带来额外的好处：查询可以从从节点走，分担主节点的压力。日志查询天然对一致性要求不高，读稍微滞后几秒完全没关系。

// 连接 MongoDB 副本集 URI 示例（副本集名称为 rs0，三个节点） mongodb://node1:27017,node2:27017,node3:27017/?replicaSet=rs0

5.2 分片：什么时候才真的需要

如果单台服务器的存储和写入能力成为瓶颈，再考虑分片。分片的本质是把数据按照片键分布到多个节点上。日志场景选用分片有两个常见策略：range 分片和 hashed 分片。

Range 分片在日志系统里有个很天然的诱惑：时间是一个天然的 range 键，按时间分片可以保证“最近的日志都落在同一个分片上”。但这样做有个致命缺点——写热点。日志永远是新数据写入最多，如果按时间分片，所有新日志都往最后一个分片写，其他分片闲着，等于没有分片。

所以我建议用 hashed 分片，把日志的某个维度（比如traceId或随机_id）做哈希，让写入均匀分布到多个分片。代价是范围查询要广播到全部分片再合并结果，但日志查询本身会带时间范围，配合索引也能接受。

// 对日志集合进行分片，片键为 hashed(traceId) sh.shardCollection('logs.app_log_20250115', { traceId: 'hashed' })

5.3 数据分层：热数据难道就不能进 MongoDB 了吗

有些日志系统非常庞大，需要做冷热分层。热数据实时查询用 MongoDB，冷数据转存到廉价对象存储或者压缩归档。

MongoDB 分表设计天然方便这种分层：每天/每月一个集合，到期后除了 TTL 删除，也可以把整个集合导出归档，然后再把 MongoDB 中的数据清掉或直接 drop 表。这个操作比在单一大表里挑着删要舒服太多。

这里建议给“归档 + 删除”设计一个自动化流程，不然手工操作很容易漏，时间一长磁盘就爆了。流程可以是：定时任务扫描所有日志集合，找到超过保留周期的，将其 mongodump 到归档存储，然后 drop 集合。

6. 生产环境实测中的七个典型坑

光讲设计保鲜没有意义，生产环境的坑才是真正让人成长的教材。我在这里把实际项目中踩过的坑、调过的查过的大坑列出来，希望能帮你避开。

6.1 TTL 清除风暴与删除延迟

TTL 机制虽然好用，但它其实是把双刃剑。它的删除速度跟不上写入速度时，过期数据会积压。更麻烦的是，TTL Monitor 每隔 60 秒扫一次，如果积压的数据非常多，某一次突然删除大量文档，会瞬间拉高磁盘 IO，影响正常写入。

我的对策有三个：一是分表粒度足够小，保证每个集合的数据量在可控范围内；二是关注 TTL 删除的延迟指标，如果出现积压，手工分批删一部分过期数据，让 TTL Monitor 喘口气；三是错峰写入，尽量减少日志写入和 TTL 清理在同一时间段的资源争抢。

6.2 集合数量过多引发的元数据压力

分表方案用久了，一个隐藏问题浮出水面：集合数量越来越多。按天分表跑一年就有 365 个集合，三年就是上千个。MongoDB 每个集合都有元数据，集合太多时，db.stats()变慢、mongod 启动变慢、甚至内存占用都会上升。

解决思路是给集合设置保留数量的上限。超出保留期的集合，不但数据被 TTL 清空，整个集合也要 drop 掉，不要把它留在里面吃内存。这个动作建议做成自动化脚本定时执行，别等手动想起来。

6.3 文档体积与索引选择的隐性陷阱

日志系统的文档一般来说都很小，但如果有人把整段堆栈、整个请求报文都塞进 message，文档体积就会快速膨胀。单个文档变大，内存里放不下，查询时要从磁盘读入的页就变多，性能成倍下降。

另外，不是所有日志字段都需要索引。每个索引都有写入时的维护成本，日志是高频写入，索引要克制。我见过一个项目把所有字段都建了索引，结果写入性能被拖到惨不忍睹。日志集合里索引数量控制在 3 个以内是比较健康的状态。

6.4 时区与时间字段的坑

时区问题在日志系统里特别容易踩。如果你在应用层把本地时间转成字符串存进去，比如"2025-01-15 23:59:59"，这个字段就废了——不管是范围查询、排序还是 TTL 过期，都会因为字符串比较规则而产生奇怪的结果。

我的原则是：数据库里一律存 UTC 时间的 BSON Date，展示层再转本地时区。这样即使服务器分布在多个时区，日志的时间线也是统一的。还有一个小细节：TTL 索引比较的是文档里那个字段的时间，所以字段存的是什么含义就明确是什么，别把“采集时间”和“产生时间”混着存，这是最容易让日志出现“提前过期”或“过期不清理”的根源。

6.5 磁盘空间回收的假象

日志删了，磁盘空间并没有立刻变少。这是 MongoDB 存储引擎的行为——删除数据后会释放内部的数据页，但这些页会留在存储引擎的空闲列表里，给后续写入复用，而不是直接交还给操作系统。

如果你发现删了一堆日志，df 看磁盘还是满的，别慌，这是正常现象。要让空间真正还给系统，还得执行compact操作。但在生产环境对一个大集合执行 compact 是相当危险的动作，建议先在从节点上做，再切换角色，不然阻塞写入的代价你承担不起。

6.6 慢查询扫描导致的全集合风险

日志集合的查询如果没走索引，就是全集合扫描。数据量上来之后，这个操作不仅慢，还会抢大量 CPU 和内存，影响整个实例的性能。

排查慢查询的标准动作是开启 profiling 或者定期查db.currentOp()，看看有没有条数大、耗时长的查询在跑。我见过一次线上事故，就是因为有人在日志集合上执行了db.collection.find({ message: /timeout/ })这种正则，直接把数据库 CPU 打满，持续了十几分钟才被我们发现。之后我们把所有日志查询都收敛到固定的封装接口里，从代码层面限制查询方式，才从根本上避免这类问题。

6.7 备份与保留策略的冲突

日志系统的备份和普通业务库不一样。普通业务库你可能需要全量备份，日志系统动辄几十 TB，全量备份既不现实也没必要，因为日志本身有生命周期，而且只保留 7 天 30 天。

所以日志系统的备份重点应该是：关键的数据结构（索引定义、分片配置）有文档记录，历史冷数据有归档机制，真正常态化的备份反而不那么重要。如果一定要做备份，可以只备份需要长期保留的审计日志，单独放在一个小集合里，单独备份，成本低，需要时也找得回来。

写在最后

我在实际项目里把这套方案落地过两轮，最大的感受可以用一句话总结：日志系统的设计拼的不是什么高深技术，而是对数据生命周期的清醒认知。你设计的不是存储结构，是一条从产生到入库、到查询、再到销毁的完整数据流水线。每个环节想清楚“数据在这个阶段有多大的量、多高的频次、多久的生命周期”，方案自然就清晰了。

如果你正准备动手做一套 MongoDB 日志系统，我的建议是不要一上来就引入多复杂的架构，先用单集合 + TTL 跑通链路，观察写入和查询的瓶颈在哪里，再决定要不要分表、要不要分片。很多系统在 80% 的规模下根本不需要分片，把基础做好就够了。最后一个小技巧：日志集合的索引和 TTL 创建脚本，一定要跟你建集合的自动化脚本放一起，不然新表上线忘了建索引，第二天高峰一到就是事故。