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