同步队列工作者的访问权限

Question

我目前正在编写一项使用Steam Web API抓取DotA 2匹配的服务。因为我希望我的解决方案可扩展，所以我希望允许同时缓冲和处理爬网作业。这就是为什么想到一个队列：

所有组件都应该能够在不同的计算机/ VM上运行（无内存或进程间同步）。爬行工作可能是这样的：

Job 1: Crawl match 1234 with options ABC
Job 2: Crawl match 2345 with options BCD

由于数据的性质，指向相同匹配的多个作业可能被排队（例如，两个玩家玩同一游戏）。因此，我需要一些队列无法提供的同步机制（爬虫不得尝试同时写入相同匹配的数据）。

我的实际问题是：是否有一种模式可用于同步需要访问相同数据的队列工作者？

我想到的一种方法是引入另一种服务，允许抓取工具进行Lock匹配（需要在读取或写入数据库中的匹配数据之前完成）：

但这会引入一大堆新的问题和要求：

• 如何缩放控制器？
• 如果控制器崩溃怎么办？
• 如果队列工作人员没有解锁匹配怎么办？
• ...

如果感兴趣，我可能会使用以下技术：

• 队列：Windows Server的服务总线
• 服务：.NET Web API
• DB：SQL Server 2012

Answer 1

这听起来像预订系统，这是在线机票预订系统所具有的那种问题 -

user asks for tickets
system offers specific tickets
user thinks a while and maybe pays, during that think time system cannot offer tickets to anyone else
eventually user buys, rejects or maybe just times out
system updates ticket availability

问题：如果两个具有相同参数的爬虫在同一时间搜索，并且他们无法同时更新结果，那么在您的系统中是否存在问题？ 我问的原因是我认为爬行动作本身就像用户思考时间一样，这是一个长期运行的动作，持续数据库持有数据库是不合理的 锁。

我建议的计划是  乐观锁定，由数据库和数据库转换调解，因此不需要单独的控制器 - 您的数据库是单点故障，最终是可扩展性瓶颈，但您可以通过DB的某些分区来解决这个问题。

你需要某种控制器。但它不一定是单身人士。再次通过数据库锁来调解实例。我看到的一个大问题是能够可靠地捕获失败的爬虫。在“蓝天”场景中维护运行爬虫的数据库表非常容易。在我看来，失败的情况非常棘手。

我想知道诀窍是分区数据库，每个分区对应一个带有自己控制器的“工作组”。只要控制器处于活动状态，它就可以启动工作并监控查询，以便在其工作组中不会出现重复项。完成任何爬网程序后，“就绪”消息将排队，结果整合服务将数据从分区拉入主服务器。

Answer 2

如果您需要关联队列中的一组/一组消息，则可以使用Sessions。同时使用具有多个订阅的单个主题可以是基于订阅上设置的不同过滤器对消息进行分区的好方法。以下信息可能会有所帮助：

1. （来自我的博客）http://abhishekrlal.wordpress.com/2012/02/07/enterprise-integration-patterns-with-service-bus-part-1/
2. http://code.msdn.microsoft.com/windowsazure/Brokered-Messaging-Session-41c43fb4

您可能需要将上述示例中的引用更新为Azure SDK 1.8，因为它支持适用于Windows Server的Service Bus 1.0。