我正在尝试使用MSMQ实现作业队列，以节省一些时间在SQL中实现它。读完后我意识到MSMQ可能不会提供我所追求的东西。如果我的计划使用MSMQ是现实的还是推荐替代方案，请指教我？
我有多个进程从队列中取出作业（我可能需要在将来扩展），一旦找到作业处理，在此期间作业被状态锁定到其他进程，如果需要作业是将状态更改（状态再次更改）返回队列以进行进一步处理，但物理上该作业仍然在队列中直到完成。
MSMQ不允许我在处理消息时将消息保留在队列中，例如我可以查看或阅读。 Read将消息从队列中取出，并且peek不允许更改消息（状态）。
谢谢
答案 0 :(得分：1)
使用MSMQ作为数据存储区可能很糟糕，因为它根本不是为存储而设计的。除非队列是事务性的，否则消息甚至可能无法写入磁盘。
由于您声明的原因，当然不支持原位更新队列项。
如果你不想要一个完整的关系数据库，你可以使用某种类型的内存缓存，比如memcached，或者像raven这样的廉价对象数据库。
答案 1 :(得分：0)
查看RabbitMQ或许多其他消息队列。大多数提供开箱即用的功能。
例如。 RabbitMQ调用你所描述的工作队列。多个消费者可以从同一队列中拉出而不拉同一个项目。此外，如果您使用确认并且处理失败，则不会从队列中删除该项目。
.net示例： https://www.rabbitmq.com/tutorials/tutorial-two-dotnet.html
编辑：在我自己使用MSMQ之后，就我所知，它可能会非常适合你正在做的事情。关键是使用事务和多个队列。例如，每个状态都应该拥有自己的队列。移动＆＃34;相当安全。消息从一个队列到另一个队列，因为它发生在事务中。这种消息的移动基本上是你的状态变化。
我们还使用Message Extension字节数组来存储消息元数据，例如status。这样，我们就不必在将其移动到另一个队列时更改实际消息。
MSMQ和队列通常需要一组不同于大多数程序员使用的模式。记住这一点。
或许，如果您可以提供有关您需要查看当前正在处理的消息的原因的更多信息，则可以使用MSMQ来处理该方案。您可以随时添加数据库以进行其他跟踪。