在Windows中构建具有修改后的FIFO语义的工作项处理系统

Question

我构建了一个系统，该系统生成排队等待后端处理的“工作项”。我最近完成了一个具有相同要求的系统，并提出了一种我认为不是最佳的体系结构，并希望为这个新系统提供一些建议。

工作项目集中排队，需要按基本先进先出顺序处理。如果这是唯一的要求，那么我可能会倾向于使用MSMQ或SQL Server Service Broker解决方案。但是，实际上，我需要以修改后的FIFO顺序选择工作项目。工作项目具有多个属性，并且需要按照先进先出的顺序进行分配，这些属性值存在某些组合。

作为示例，工作项目可能具有以下属性：办公室，优先级，组号和序号（在组内）。当多个项目排队等待相同的组号码时，它们保证按序列号顺序排队并具有相同的优先级。

有几个后端进程（当前实现为Windows服务），根据给定服务的某些配置参数，以修改的FIFO顺序提取工作时间。运行华盛顿特区的服务配置为仅处理DC的工作项目，而纽约的服务可配置为处理NY和DC项目（主要用于提高整体吞吐量）。除了这种选择性之外，还应首先处理较高优先级的项目，并且包含相同“组编号”的项目必须按顺序编号顺序进行处理。因此，如果NY服务正在使用序列1处理组100中的DC项目，我不希望DC服务在组100中排除DC项目2，因为序列1尚未完成。其他组中的项目仍应符合处理条件。

在上一个系统中，我使用SQL表实现了队列。我创建了存储过程来提交项目，更重要的是，将项目“分配”给负责处理它们的Windows服务。赋值存储过程包含上面描述的选择逻辑。每个Windows服务都会调用分配存储过程，并向其传递该服务实例特有的参数（例如符合条件的办公室）。此分配存储过程为分配（正在处理）的工作项目进行标记，当工作完成时，会调用最终存储过程以从“队列”（表格）中删除项目。

该解决方案确实具有一些优点，可以通过简单的SQL select语句快速检查这些“队列”的状态。我也能够轻松地操作队列（例如，我可以用简单的SQL更新语句来优先考虑）。然而，在不利的方面，我偶尔不得不处理这些队列表上的死锁，并且有写这些存储过程的负担（过一​​段时间会变得乏味）。

不知何故，我认为MSMQ（有或没有WCS）或Service Broker应该能够提供更优雅的解决方案。滚动我自己的排队/工作项目处理系统只是感觉不对。但据我所知，这些技术在分配过程中并不能提供我需要的灵活性。我希望我错了。任何的建议都受欢迎。

Answer 1

队列用于FIFO顺序，而不是随机访问顺序。即使你说你想要先进先出（FIFO）顺序，你也需要关于随机变量的FIFO顺序，这实质上是随机顺序。如果你想使用队列，你需要能够在消息进入队列之前确定顺序，而不是在队列进入之后。

Answer 2

在我看来，你的原子工作单元的概念是一个组。所以我建议你只排队标识一个组标识的消息，然后你的工作人员将不得不转到一个将组标识映射到1个或更多工作项的表。

您可以通过使用一个以上的队列处理您的其他问题 - 纽约 - 高，NY-低，DC-高，DC-低，等

坦率地说，不过，我想你最好有助于解决您当前体系结构中的死锁问题。您应该使用更新锁定和读取过去提示来读取队列表中的TOP 1消息，按照您的优先级逻辑和您想要的任何过滤条件（Office/Location）进行排序。然后，您处理您的1条消息，更改其状态或将其移动到另一个表。您应该能够并行调用该存储过程而不会出现死锁问题。