我正在构建一个系统，用于生成排队等待后端处理的“工作项”。我最近完成了一个具有相同要求的系统，并提出了一种我认为不是最佳的架构，并希望为这个新系统提供一些建议。
工作项集中排队，需要以基本的FIFO顺序处理。如果这是唯一的要求，那么我可能会支持MSMQ或SQL Server Service Broker解决方案。但是，实际上，我需要以修改的FIFO顺序选择工作项。工作项具有多个属性，需要按FIFO顺序分配属性值的某些组合。
例如，工作项可能具有以下属性：Office，Priority，Group Number和Sequence Number（在组内）。当多个项目排队等候相同的组编号时，它们将保证按顺序编号顺序排队，并具有相同的优先级。
在给定服务的某些配置参数的情况下，有几个后端进程（当前实现为Windows服务）以修改的FIFO顺序拉动工作时间。运行华盛顿特区的服务配置为仅处理DC的工作项，而NY中的服务可配置为处理NY和DC项目（主要用于增加总体吞吐量）。除了这种类型的选择性之外，应首先处理更高优先级的项目，并且必须按序列号顺序处理包含相同“组号”的项目。因此，如果NY服务正在处理组100中具有序列1的DC项目，则我不希望DC服务拉出组100序列2中的DC项目，因为序列1尚未完成。其他组中的项目仍有资格进行处理。
在上一个系统中，我使用SQL表实现了队列。我创建了存储过程以提交项目，更重要的是，将“分配”项目分配给负责处理它们的Windows服务。赋值存储过程包含我在上面描述的选择逻辑。每个Windows服务都会调用分配存储过程，向其传递该服务实例唯一的参数（例如符合条件的办公室）。此分配存储过程将工作项标记为已分配（正在处理），并且当工作完成时，将调用最终存储过程以从“队列”（表）中删除该项目。
这个解决方案确实有一些优点，我可以通过简单的SQL select语句快速检查这些“队列”的状态。我也能够轻松地操作队列（例如，我可以使用简单的SQL更新语句来优先处理优先级）。但是，在不利方面，我偶尔会处理这些队列表上的死锁并负担编写这些存储过程的负担（一段时间后会变得乏味）。
不知何故，我认为MSMQ（有或没有WCS）或Service Broker应该能够提供更优雅的解决方案。滚动我自己的排队/工作项处理系统只是错了。但据我所知，这些技术无法提供我在分配过程中所需的灵活性。我希望我错了。任何的建议都受欢迎。
答案 0 :(得分：2)
在我看来，你的原子工作单元的概念是一个集团。因此，我建议您只排队标识组ID的邮件，然后您的工作人员必须转到将组ID映射到一个或多个工作项的表。
您可以使用多个队列来处理其他问题 - NY-High，NY-Low，DC-High，DC-Low等。
但是，老实说，我认为你可以更好地解决当前架构中的死锁问题。您应该使用Update Lock和Read Past提示从队列表中读取TOP 1消息，按优先级逻辑排序，以及您想要的任何过滤条件（Office / Location）。然后，您处理1条消息，更改其状态或将其移至另一个表。您应该能够并行调用该存储过程而不会出现死锁问题。
答案 1 :(得分：1)
队列用于FIFO顺序，而不是随机访问顺序。即使你说你想要FIFO顺序，你也需要关于随机变量集的FIFO顺序，这基本上是随机顺序。如果要使用队列，则需要能够在消息进入队列之前确定顺序，而不是在进入队列之后。