观察员工作者职能

如果 Node 事件循环就像一个自行车链，服务器端集合观察器就像一个变速器。当数据进入时，它将成为一种齿轮机构。它可以非常高效，因为所有的匹配自行车都有变速器。但它也是打破整个系统的源泉。这是一种高速反应功能，可以炸毁你。被警告。

Meteor.startup(function(){
  console.log('starting worker....');

  var dataCursor = Posts.find({viewsCount: {$exists: true}},{limit:20});

  var handle = dataCursor.observeChanges({
    added: function (id, record) {
      if(record.viewsCount > 10){
         // run some statistics
         calculateStatistics();

         // or update a value
         Posts.update({_id: id}, {$set:{
           popular: true
         }});

      }
    },
    removed: function () {
      console.log("Lost one.");
    }
  });
});

请注意，20 的限制是变速器的大小……它有多少齿; 或者更具体地说，当光标在集合上行走时，光标中有多少项。在这种功能中使用’var’关键字时要小心。尽可能少地将对象写入内存，并专注于添加的方法内的对象重用。当打开 opslog，并且这个东西全速运行时，如果它将对象写入内存堆的速度比 Node 垃圾收集器能够清理的速度快，那么它就是暴露令人讨厌的内存泄漏的主要候选者。

上述解决方案不能横向扩展，因为每个 Meteor 实例都会尝试更新相同的记录。因此，为了横向扩展，需要某种环境检测。

有关在群集中的多台计算机上同步服务工作者的绝佳示例，请参阅 percolatestudios:synced-cron 软件包。
流星同步 -的 cron