MongoDB创建文档触发重复键错误致服务崩溃求助

首先，咱们把问题拆解清楚——你碰到的E11000重复键错误，连带引发服务崩溃，核心原因和解决思路可以分成这几步来看：

先搞懂错误本身 #

你给出的错误信息指向性很强：

errmsg: 'E11000 duplicate key error collection: db.events index: calendar_1_providerId_1 dup key: { : ObjectId('59c58ac77f8b539bacaa49f0'), : "osv8g39so6q0cptpjhj2kk5ps4_20170602T153000Z" }'

这个错误说明：你要插入的文档中，calendar和providerId的组合值已经在db.events集合里存在了。你提到“已有不同calendarId的文档使用了相同providerId”，这其实和组合唯一索引不冲突——组合索引限制的是calendar+providerId的配对不能重复，而非单独的providerId不能重复。

但如果确实是不同calendar+相同providerId触发了错误，那大概率是你对稀疏索引的行为理解有误：

• 稀疏索引(sparse: true)只会包含有索引字段的文档，但如果你的某些文档里calendar或providerId是null（或者压根没这个字段），MongoDB会把所有null值当成同一个键。比如两个文档都没有calendar字段，那它们在索引里的calendar值都是null，此时如果providerId相同，就会触发重复键错误。

另外，重复键错误本身不会直接搞垮MongoDB，大概率是你的应用没正确捕获这个异常，导致大量重试或者错误堆积，最后把服务压崩了。

分步解决问题 #

1. 定位重复的文档 #

先确认到底是哪组组合重复了，执行这条查询：

db.events.find({
  calendar: ObjectId('59c58ac77f8b539bacaa49f0'),
  providerId: "osv8g39so6q0cptpjhj2kk5ps4_20170602T153000Z"
})

如果返回了文档，说明这个组合确实已经存在，你要么修改要插入的文档，要么处理掉已有的重复文档即可。

2. 修正索引配置（如果是null值引发的冲突） #

如果是因为部分文档缺少calendar或providerId字段（值为null）导致的问题，推荐用部分索引替代稀疏索引（MongoDB 3.2+支持），它比稀疏索引灵活得多，能精确指定哪些文档要被索引：

eventSchema.index(
  { calendar: 1, providerId: 1 },
  { 
    unique: true,
    partialFilterExpression: {
      calendar: { $exists: true, $ne: null },
      providerId: { $exists: true, $ne: null }
    }
  }
);

这样一来，只有同时存在calendar和providerId且值不为null的文档才会被加入索引，就不会因为null值的组合触发错误了。

要是你必须保留稀疏索引，那就要确保所有插入的文档都包含这两个字段，且值不能为null。

3. 完善应用的异常处理逻辑 #

为了避免这种错误搞崩服务，你的应用必须捕获E11000错误码，并做合理处理：

• 插入/更新时，一旦捕获到这个错误，要么返回友好提示给用户，要么根据业务逻辑跳过重复文档，或者做有限次数的重试。
• 绝对不能让无限制的重试逻辑跑起来，不然大量请求堆积肯定会压垮服务。

4. 修复MongoDB（如果已经宕机） #

要是MongoDB已经挂了，先重启服务，然后查看日志确认是否有其他潜在问题（比如磁盘空间不足、索引损坏等）。如果是索引损坏，可以用这条命令修复：

db.events.reIndex()

总结 #

核心问题要么是你要插入的calendar+providerId组合真的重复了，要么是稀疏索引对null值的处理引发了意外冲突。只要按上面的步骤定位问题、调整索引、完善异常处理，就能解决这个问题，还能避免以后再出现服务崩溃的情况。

内容的提问来源于stack exchange，提问作者akila arasan