mongodb中事件溯源需避免嵌入数组导致超限，应采用独立事件文档+有序时间戳+复合索引+ttl管理。每个事件含aggregateid、type、version、timestamp和原始payload，禁存冗余状态，_id或timestamp须建索引以保障时序查询效率。
事件溯源（Event Sourcing）在MongoDB中不是开箱即用的模式，必须手动建模并规避几个关键陷阱——比如文档无限膨胀、查询反模式、时序一致性丢失。直接把事件全堆进一个数组字段里，events很快会撑爆16MB限制，且无法高效分页或按时间范围检索。
用独立事件文档 + 有序时间戳代替嵌入数组
别把所有事件塞进一个文档的events数组里。每个事件应是独立文档，带明确的timestamp和version（或sequence），并用aggregateId关联聚合根。
- 每个事件文档大小可控，避免单文档超限
- 天然支持按
timestamp范围查询、分页、TTL自动过期 - 写入并发安全：多个服务可同时向同一
aggregateId追加事件，无更新冲突 - 示例结构：
{ "_id": ObjectId("..."), "aggregateId": "order-789", "type": "OrderCreated", "version": 1, "timestamp": ISODate("2026-07-21T16:02:15Z"), "payload": { "userId": "u123", "items": [...] } }
避免在事件文档中存冗余聚合状态
事件是不可变事实，不是快照。不要在事件里存currentStatus、totalAmount这类计算结果——它们该由读模型（Projection）生成，否则会导致状态不一致和重构困难。
- 冗余字段随业务逻辑变化而失效，但事件不能改
- 投影服务从事件流重放时，若依赖事件里的“当前值”，会跳过中间变更
- 正确做法：只存触发该事件的原始输入（如
amount、statusChange），由消费者累加或判断
为高频查询建复合索引，而非仅靠_id
查某个订单的所有事件，靠find({ aggregateId: "order-789" })默认走全表扫描。必须显式建索引，且顺序影响排序效率。
- 常用查询模式是“按聚合ID + 时间升序”，索引应为：
db.events.createIndex({ "aggregateId": 1, "timestamp": 1 }) - 如果还要按事件类型过滤（如只查
PaymentProcessed），可扩展为：{ "aggregateId": 1, "type": 1, "timestamp": 1 } - 注意：MongoDB不支持在数组字段上对
timestamp做范围查询——所以事件绝不能嵌套在数组里
用TTL索引管理冷事件，而不是删文档
事件要长期保留以支持审计和重放，但旧事件访问频次极低。硬删除会破坏事件链完整性；用TTL索引让MongoDB自动归档或清理更稳妥。
- 设置
expireAfterSeconds基于timestamp，例如保留2年：db.events.createIndex({ "timestamp": 1 }, { expireAfterSeconds: 3600 * 24 * 365 * 2 }) - TTL后台线程每60秒检查一次，不阻塞写入
- 生产环境建议先将冷事件导出到对象存储（如S3），再TTL清理，避免永久丢失
最易被忽略的一点：事件文档的_id必须能体现时序或可排序性。ObjectId本身含时间戳，但若用字符串ID或UUID，就得额外依赖timestamp字段——而这个字段一旦没建索引，sort({ timestamp: 1 })就会变成内存排序，极易OOM。
