我需要以可靠/事务的方式为外部系统排队事件和任务。使用 MSMQ 或 ActiveMQ 之类的东西看起来很诱人，但事务部分变得复杂（MSDTC 等）。
我们可以使用数据库（SQL Server 2005+、Oracle 9+）并实现更轻松的事务支持，但排队部分变得更丑陋。
这两条路线似乎都不是那么好，并且充满了令人讨厌的陷阱和极端情况。
有人可以在这件事上提供一些实用的指导吗？
想一想：E/C/A 或者一个定时任务引擎，每隔一段时间就会唤醒，看看此时是否有定时任务需要运行（即 next-run-date 已经过了，但是 expire-date 还没到到达）。
我们的系统有 60 台计算机，每台计算机运行 12 个任务（线程），需要“获得下一个工作”。总而言之，每天有 5 万个“工作”。计算每分钟有多少事务并意识到任务时间是可变的，因此可以同时获得多个“弹出”事件。
我们的第一个版本使用 MSMQ。结论：远离。虽然它在负载和同步问题上做得很好，但它有两个问题。一个烦人，一个破坏交易。
烦人：作为企业软件，MSMQ 具有安全需求，这使得设置和与客户网络管理员进行斗争成为另一件事。
交易破坏者：然后是我们想要接受下一份工作的时候了，但不是使用简单的流行音乐，而是使用“获得下一个蓝色工作”或“获得下一个黄色工作”之类的东西。做不到！
我们采用了 B 计划：使用单个 SQL 2005 表实现了我们自己的 Q。不能更快乐
我强调每天用 20 万条消息对其进行测试，成功了。我们可以根据需要使“下一个”逻辑变得复杂。
问题：您需要非常小心获取下一项的 SQL。因为您希望它快速且非锁定。根据一些研究，我们使用了2 个非常重要的 SQL提示。魔法是这样的：
SELECT TOP 1 @Id = callid
FROM callqtbl WITH (READPAST, XLOCK)
where 1=1 ORDER BY xx,yy
我已经看到 MSMQ 以事务方式使用，它似乎并不特别复杂 - 事务 SCope 将入队或出队调用与数据库访问一起包装，只要队列在创建后被定义为事务性，一切都很好。我认为 ActiveMQ 不是这样，它是一个消息代理，但 MSMQ 本地安装在每个端点机器上，因此将项目以事务方式放入队列不需要花哨的分布式事务。
您可能已经意识到这一点，但是在 .NET 上，有一些轻量级库提供了一些对 MSMQ 的很好的抽象（理论上还有其他传输）
nServiceBus : www.nservicebus.com
公共交通：http ://code.google.com/p/masstransit/
此外，Oren Eini 有一个有趣的基于实验性文件系统的事务队列。这个库的好处是，与 MSMQ 不同，它可以作为库部署，并且不需要部署 MSMQ 的维护头痛。
你可以在这里阅读：http: //ayende.com/Blog/archive/2008/08/01/Rhino.Queues.Storage.Disk.aspx
此外，SQL Server 2005 确实使用 SQL Server Service Broker 相当优雅地处理队列，但您需要在每个端点上安装 SQL Server，而且我不知道 SSB 是否穿过防火墙。
最后，如果你在这里没有得到你想要的答案，我强烈推荐 nSERviceBus 讨论论坛。Udi Dahan 和他的一小群面向消息的追随者一起回答了这些问题，这是迄今为止我发现的最好的资源，可以快速有效地回答我的面向队列的问题。该论坛在这里：http ://tech.groups.yahoo.com/group/nservicebus/
Quartz.Net是一个开源的作业调度系统。
这就是 MSMQ 的设计目的——事务排队。如果这对您不起作用，请查看 SQL Server 的“服务代理”功能 - 它是“csmba”在他的回答中描述的“SQL 表中的队列”，但它是一个集成的 SQL Server 组件，封装得很好并暴露给您使用。
WebSphere MQ（MQ 系列）是一种选择吗？支持事务性消息传递。
您可以查看名为Advanced Queuing的 Oracle 功能