【问题标题】:Cron job for big data大数据的 Cron 作业
【发布时间】:2009-08-26 02:06:37
【问题描述】:

我正在开发一个像 Friendfeed 这样的社交网络。当用户添加他的提要链接时,我使用 cron 作业来解析每个用户提要。这对于大量用户来说是否可行,例如每小时解析 10.000 个链接,还是会导致问题?如果不可能,Friendfeed 或 RSS 阅读器使用什么来做到这一点?

【问题讨论】:

    标签: php xml rss cron


    【解决方案1】:

    您可能会考虑在您的问题中添加一些有关您的硬件的信息,这对于希望就您的实现如何轻松扩展提供建议的人来说会有很大的不同。

    如果您最终解析了数百万个链接,那么一项大型 cron 作业就会出现问题。我假设您正在执行以下操作(如果没有,您可能应该这样做):

    • 实现用户订阅同一个提要,避免获取两次。
    • 获取新提要时,检查是否存在站点地图,告诉您提要可能多久更改一次,并在合理的时间间隔内重新访问该值
    • 检查系统负载和内存使用情况,以了解何时“退出”并进入睡眠状态。

    这减少了每小时 cron 产生的汗水量。

    如果您正在收集数百万个提要,您可能希望分发该工作,在您仍在设计数据库时可能需要牢记这一点。

    再次,请更新您的问题,详细说明您正在使用的硬件以及您的解决方案需要扩展多大。没有什么是“无限”的,所以请现实一点:)

    【讨论】:

      【解决方案2】:

      没有足够的信息来判断这个设计是否好,但要回答基本问题,除非你正在对 10k 问题进行一些非常密集的处理,否则对于每小时的 cron 工作来说处理应该是微不足道的.

      有关您如何处理提要的更多信息,特别是该过程如何根据拥有提要的用户数量和每个用户的提要数量进行扩展,将有助于为您提供进一步的建议。

      【讨论】:

        【解决方案3】:

        您的限制因素将是对这 10,000 个供稿的网络访问。您可以连续处理提要,并且可能在一小时内处理 10,000 个(平均需要大约 350 毫秒的延迟)。

        当然,您希望有多个进程同时完成这项工作以加快处理速度。

        【讨论】:

          【解决方案4】:

          无论您选择什么解决方案,如果您成功(我希望如此),您将遇到性能问题。

          正如 FF 创始人多次说过的:选择最佳实际解决方案的唯一解决方案是剖析/测量。有了数字,选择就很明显了。

          所以:在几个月内构建一个接近您预期(=现实)情况的测试架构并进行配置/测量。

          【讨论】:

            【解决方案5】:

            您可能需要考虑查看IronWorker 以了解此类大数据工作。它是为它而设计的,因为它是一项服务,您不需要处理服务器或扩展。它具有内置的调度功能,因此您可以安排一个工作任务每小时运行一次,然后该任务可以将 10,000 个其他作业排队并并行运行它们。

            【讨论】:

              猜你喜欢
              • 2016-10-06
              • 1970-01-01
              • 1970-01-01
              • 1970-01-01
              • 2021-09-01
              • 2013-08-04
              • 2013-02-09
              • 2012-10-13
              • 1970-01-01
              相关资源
              最近更新 更多