![]() |
1
3
你可能应该做一个一次性的请求(每周/每月,任何合适的)。对于每个feed,按照重定向获得“true”地址。无论当时的限制情况如何,您都应该能够解析所有提要,保存该数据,然后对添加到列表中的每个新提要执行一次。你可以看看 urllib's geturl() 当它从你输入的url返回最终url时。在ping提要时,请确保使用原始的(保持“真实的”只是为了负载平衡),以确保在用户移动了提要或类似的提要时,它会正确重定向。 完成后,您可以简单地设计一个加载机制,例如对于给定的域,每小时只有x个请求,遍历每个提要并跳过其主机已达到限制的提要。如果FeedBurner保持其限制公开(不太可能),您可以将其用于X,但否则,您只需估计它,并粗略估计您知道低于限制。然而,了解谷歌,他们的限制可能衡量模式,而没有具体的硬限制。 编辑 :添加了来自评论的建议。 |
![]() |
2
2
如果你的问题与FeedBurner“限制你”有关,它肯定会这样做,因为你的机器人的源IP。“FeedBurner负载平衡”的方法是从多个不同的源IP开始。 现在实现这一目标的方法有很多,其中两种是:
当然,你现在不要在他们面前放一个新的盒子;-) 上面处理了可能的“节流问题”,现在是“调度部分”。您应该为每个“目的地”维护一个“虚拟调度程序”,并确保不超过所讨论的web服务(例如feedburner)的参数。现在,棘手的是要抓住这些“极限”…有时候它们是广告,有时候你需要通过实验来弄清楚。 我知道这是“高级架构指南”,但我还没有准备好为您编写这个…希望你原谅我;-) |
![]() |
3
1
“如何平衡传出请求的负载,以便不经常攻击任何一个主机?” 一般来说,这是通过设计更好的算法来实现的。 例如,随机地扰乱您的请求。 或者“公平地”洗牌,这样你就可以循环浏览源代码。这将是一个简单的队列列表,您在其中对每个主机的一个请求进行出列。 |