队列工作器的同步访问
我目前正在编写一个服务，它使用蒸汽Web爬行DotA 2匹配。因为我希望我的解决方案是可伸缩的，所以我希望允许同时缓冲和处理爬行作业。这就是为什么一想到排队：
所有组件都应该能够在不同的计算机/VM上运行(没有内存内同步或进程间同步)。爬行工作可能是这样的：
Job 1: Crawl match 1234 with options ABC
Job 2: Crawl match 2345 with options BCD由于数据的性质，指向同一匹配的多个作业可能会排队(例如，两个玩家玩同一游戏)。因此，我需要一些队列无法提供的同步机制(爬虫不能尝试同时写入相同匹配的数据)。
我的实际问题是:是否有一种模式可以用于同步需要访问相同数据的队列工作人员？
我想到的一种方法是引入另一种服务，允许爬行器进行Lock匹配(这需要在从数据库读取或写入匹配数据之前完成)：
但这将带来一大堆新的问题和要求：
- 如何缩放控制器？
- 如果控制器崩溃了呢？
- 如果队列工作人员不解锁匹配怎么办？
- ..。
如果感兴趣的话，下面是我可能使用的技术：
- 队列:用于Windows的服务总线
- 服务：.NET Web
- DB: Server 2012
回答 2
Stack Overflow用户
发布于 2013-03-01 02:29:59
这听起来像是预订系统，网上订票系统有这样的问题-
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是一个单一的故障点，最终是一个可伸缩性的瓶颈，但是您可以通过对DB进行一些分区来解决这个问题。
你需要某种控制器。但不一定是单身。同样，通过数据库锁来中介实例。我看到的大问题是可靠地捕捉失败的爬虫。在“蓝天”场景中，很容易维护运行爬虫的DB表。在我看来，失败的情况是非常棘手的。
我不知道诀窍是否是对数据库进行分区，每个分区对应于一个带有自己控制器的“工作组”。只要控制器是活动的，它就可以启动工作，并对查询进行监管，这样就不会在其工作组中出现重复的情况。在完成任何爬虫时，都会有“就绪”消息排队，结果合并服务会将数据从分区中提取到主服务器。
Stack Overflow用户
发布于 2013-03-01 06:23:47
如果需要将队列中的一组/一组消息关联起来，则可以使用会话进行关联。此外，使用具有多个订阅的单个主题可以根据订阅上设置的不同筛选器对消息进行分区。以下信息可能会有所帮助：
- (从我的博客) http://abhishekrlal.wordpress.com/2012/02/07/enterprise-integration-patterns-with-service-bus-part-1/
- http://code.msdn.microsoft.com/windowsazure/Brokered-Messaging-Session-41c43fb4
您可能需要将上述示例中的引用更新到AzureSDK1.8，因为这正是支持Windows服务总线1.0的地方。
https://stackoverflow.com/questions/15154645
复制
相似问题
使用基于类的视图和ajax的Django应用程序？
用于处理AJAX响应的基于django类的视图
使用基于Django类的视图处理AJAX时遇到问题
基于Django类的视图
基于类的视图Django
领取专属 10元无门槛券
AI混元助手 在线答疑
洞察 腾讯核心技术
剖析业界实践案例
腾讯云开发者
