先说几个核心结论：在设计 MongoDB 活动报名系统时，最根本的防超卖防线是唯一索引，而不是依赖代码层的“乐观锁”或“先查后写”。不少从关系型数据库转型的开发者，第一反应会寻找类似SELECT…FOR UPDATE的锁机制——但请记住，MongoDB 本身不支持这样的行级锁。真正能兜底的方案，是唯一索引配合原子写入，并在应用层增加简单的重试逻辑。
许多团队都踩过这样的坑：以为使用findAndModify加上版本号就能应对并发超报，结果一到高并发场景，名额依然超卖，数据依然脏读。根本原因在于，你期望 MongoDB 实现 MySQL 那种行级锁控制，但它根本不支持。唯一的出路，是把约束条件提前压缩到索引层。
为何必须用唯一索引来防止重复报名
活动报名中最严峻的并发问题，并非“抢最后一个名额”，而是“同一用户反复报名同一活动”。MongoDB 没有外键、没有跨文档事务、也没有隔离级别控制，唯一能依赖的数据库级防线，就是唯一索引。
具体而言，activity_registration 集合必须创建一个复合唯一索引：{ user_id: 1, activity_id: 1 }。这个索引的设计有讲究——单字段索引，例如只对user_id或只对activity_id建立唯一索引，完全无效。为什么？因为单字段唯一索引只能保证单个字段的值不重复，而你的业务约束是“同一用户不可重复报名同一活动”，这是两个字段组合起来的约束。
如果遗漏了这个索引，高并发下两条相同的{ user_id: 123, activity_id: 456 }请求很可能同时写入，MongoDB 默认允许这样做——直到应用层后续查重才发现，但此时名额已经超了，数据也已脏掉。
还有一点必须警惕：创建索引之前，一定要先清理集合中的历史重复数据。否则执行createIndex(..., { unique: true })会直接报错E11000 duplicate key error，导致索引无法创建。
如何用原子操作校验并扣减剩余名额
说到名额扣减，核心原则是：不要先读再改，而要用updateOne一次完成判断与更新。MongoDB 能保证单文档操作的原子性，因此名额字段必须放在活动主文档里（即activity集合），不能分散到报名表中去计算。
一个典型的活动文档结构如下：{ _id: ObjectId("..."), name: "春游", capacity: 100, registered_count: 42, status: "published" }。
报名时的核心操作是：db.activity.updateOne({ _id: activityId, status: "published", registered_count: { $lt: capacity } }, { $inc: { registered_count: 1 } })。注意这里的关键条件registered_count: { $lt: capacity }——它确保只有名额还有富余时才会执行扣减。
然后检查返回的result.matchedCount：如果为1，代表名额充足且已扣减成功；如果为0，说明已满或活动状态异常，此时不应再插入报名记录。注意，千万不要用find+updateOne两步走的方式——中间那个时间窗口，完全可能被其他请求抢占掉。
报名写入与唯一索引冲突的处理方式
即使做了上述校验，仍然可能因为网络重试、前端重复提交等场景，导致往activity_registration插入数据时触发唯一索引报错。这不是 bug，而是预期行为，必须在代码里显式捕获并处理。
这个错误信息形如：WriteError: E11000 duplicate key error collection: db.activity_registration index: user_id_1_activity_id_1 dup key: { user_id: 123, activity_id: 456 }。捕获到之后，直接返回“您已报名”即可，而不是抛出“系统错误”把用户搞懵。
有同学会想：那我能不能先findOne查一下，没记录再插入，这样不就避开了报错？千万不要。这又回到了非原子操作的老路，而且多了一次查询开销，在高并发下查完到写入之间，别人可能已经插入了。
如果业务允许“取消后重报”的场景，那么插入时可以加upsert: true并设置status: "registered"，但必须确保更新操作也带条件——比如仅当当前状态不是canceled时才生效。
分片集群下唯一索引的特殊限制
如果你的activity或activity_registration集合启用了分片，那么唯一索引就不能“无脑加”了。MongoDB 有一个严格限制：任何唯一索引，其字段组合必须包含分片键作为前缀，否则创建失败。
举个例子：如果activity_registration按activity_id分片，那么{ user_id: 1, activity_id: 1 }可以建唯一索引，因为activity_id是它的前缀；但如果只建{ user_id: 1 }这个单字段唯一索引，就会被拒绝。
这意味着什么？如果你计划按用户维度分片，那user_id就必须出现在所有唯一索引中——设计初期就得定死分片策略，后期基本没法改。
另外，线上环境建唯一索引时，务必确认当前是在副本集还是分片集群上。如果是集群环境，必须停写或使用滚动构建，否则可能阻塞整个集合的写入操作。
说到底，真正难的不是写几行createIndex代码，而是在分片、扩容、多服务共写同一个集合的情况下，依然保证唯一性约束不被绕过。索引建错一次，修复成本远高于初期多想五分钟。
