我正在构建一个系统来生成排队等待后端处理的“工作项”。我最近完成了一个具有相同要求的系统，并提出了一个我认为不是最佳的架构，并希望为这个新系统提供一些建议。
工作项目集中排队，需要以基本上先进先出的顺序进行处理。如果这是唯一的要求，那么我可能更喜欢 MSMQ 或 SQL Server Service Broker 解决方案。但是，实际上，我需要以修改后的 FIFO 顺序选择工作项。一个工作项有几个属性，在存在某些属性值组合的情况下，它们需要按 FIFO 顺序分配。
例如，工作项可能具有以下属性：办公室、优先级、组号和序列号（组内）。当多个项目为同一个组号排队时，它们保证按序号顺序排队，并且具有相同的优先级。
在给定服务的某些配置参数的情况下，有几个后端进程（当前实现为 Windows 服务）以修改后的 FIFO 顺序拉取工作时间。运行 Washington, DC 的服务被配置为仅处理 DC 的工作项，而 NY 的服务可能被配置为同时处理 NY 和 DC 的项目（主要是为了提高整体吞吐量）。除了这种选择性之外，优先级较高的项目应该先处理，包含相同“组号”的项目必须按照序列号顺序处理。因此，如果 NY 服务正在处理具有序列 1 的组 100 中的 DC 项目，我不希望 DC 服务取消组 100 序列 2 中的 DC 项目，因为序列 1 尚未完成。其他组中的项目应该仍然有资格进行处理。
在上一个系统中，我使用 SQL 表实现了队列。我创建了存储过程来提交项目，更重要的是，将项目“分配”给负责处理它们的 Windows 服务。赋值存储过程包含我上面描述的选择逻辑。每个 Windows 服务都将调用分配存储过程，向其传递对该服务实例（例如，符合条件的办公室）唯一的参数。此分配存储过程将工作项标记为已分配（处理中），当工作完成时，调用最终存储过程以从“队列”（表）中删除该项目。
这个解决方案确实有一些优势，因为我可以通过一个简单的 SQL 选择语句快速检查这些“队列”的状态。我还能够轻松地操纵队列（例如，我可以使用简单的 SQL 更新语句来提高优先级）。然而，不利的一面是，我有时不得不处理这些队列表上的死锁，并且有编写这些存储过程的负担（一段时间后会变得乏味）。
不知何故，我认为 MSMQ（带或不带 WCS）或 Service Broker 应该能够提供更优雅的解决方案。滚动我自己的排队/工作项处理系统感觉不对。但据我所知，这些技术无法提供我在分配过程中所需的灵活性。我希望我错了。任何的建议都受欢迎。