Javascript 使用Meteor和moment.js是否有一种标准方法可以在特定时间从集合中删除Mongo文档？

我正试图找到一种更好的方法来确保在特定时间从mongo集合中删除某些文档，这是每个文档所特有的。当项目被删除时，我还需要运行一些方法。我已经研究了TTL索引，但它们似乎不允许任何类型的回调，而且从我所读到的内容来看，删除文档的过程每分钟只运行一次，这对于我所需要的不够具体。以下是我的想法：

var check_frequency = 30000;
Meteor.setInterval((function() {
    // figure out what elements will expire within the next check period
    var next_check = moment().add(check_frequency, 'milliseconds');
    var next_string = next_check._d.toISOString();

    var ending_items = items.find({'time_to_end': {$lt : next_string}});

    ending_items.forEach(function(db_object) {
        var time_from_now = moment(db_object.time_to_end) - moment();
        Meteor.setTimeout(function() {
            removeAndReport(db_object._id);
        }, time_from_now);

    });
}), check_frequency);

我担心的是，我不确定Meteor.setTimeout（）如何处理线程，所以如果我有成百上千个这样的调用，我想知道它是否会导致问题。有人能推荐一种更好的方法来实现这一点吗

提前谢谢

---

编辑：使用Meteor或cron运行后台作业不是我唯一关心的问题。我意识到我可以用cron作业完成同样的事情，但我不希望每秒查询一次数据库，只找到3个过期项目，而不是每30秒查询一次数据库，并找出哪些元素将在下一个时间段过期。

似乎更简单的解决方案是在每个文档中存储删除日期，而不是TTL。假设您有一个名为

Messages

的集合，每个文档都有一个

removeAt

字段。然后您可以执行以下操作：

var timeout = 500;
Meteor.setInterval((function() {
  // remove any messages that should have been removed in the past
  Messages.remove({removeAt: {$lte: new Date}});
}), timeout);

注:

确保索引

removeAt

，这样

remove

就不需要扫描整个收藏

从技术上讲，如果它在多个服务器实例上运行，它不会崩溃，但理想情况下它只能在一个服务器实例上运行。也许它可以在自己的过程中运行

---

如果你在《流星》中有一些看起来像是常规背景任务的东西，你应该首先尝试。这可能是你想要的。我用编辑指定了我的问题。无论我是使用Meteor还是cron任务来运行流程，如果可能存在数千个实例，上述方法是确保在特定时间发生事情的最佳方法吗？实例是需要删除的文档，还是应用程序的运行实例？另外，你能更深入地解释一下这些限制吗？例如，如果某个特定文档恰好在TTL vs结束时（比如5分钟后）被删除，这是否重要？我还为这个问题添加了一个关键点：时间对于数据库中的每个文档都是唯一的。因此，它不可能是一个对所有文档都通用的计划任务，因为具体的删除时间会有所不同。请重新打开。一个“实例”将是一个删除和处理文档的计划方法，很抱歉措辞不正确。我需要将文档删除到特定的一秒钟，并且我不一定要每秒运行一次查询。具体来说，我正在尝试建立一个拍卖行，并将拍卖品存储在数据库中。我需要拍卖在特定时间后到期，我希望结算拍卖的方法按间隔设置，而不是根据拍卖持续时间设置超时。我想我可以在到期时间后阻止出价，然后像你建议的那样在以后删除拍卖，但在我的程序中还有一些类似的情况，我正努力想弄清楚。我绝对建议在过期后阻止投标——这应该很容易实现，并提供了一个强有力的一致性保证。至于精度，上面的示例每0.5秒删除一次-如果需要，当然可以降低。一个每秒几次快速运行的查询不应该造成任何明显的数据库负载，除非每秒有数千次拍卖结束。但是数据库的大小有关系吗？如果我有一个有几千次拍卖的数据库，每秒运行一次查询不会影响性能吗？我对这样的负载测试没有太多经验。没有一个文档被

removeAt

索引。无论文档的数量如何，查询都会立即找到需要删除的文档，而无需扫描整个集合。如果它没有被索引，你会有一个性能问题。