我需要以可靠/事务方式为外部系统排队事件和任务。使用像MSMQ或ActiveMQ这样的东西看起来非常诱人，但事务部分变得复杂（MSDTC等）。
我们可以使用数据库（SQL Server 2005 +，Oracle 9+）并实现更简单的事务支持，但排队部分变得更加丑陋。
这两条路线看起来都不那么好，并且充满了讨厌的陷阱和边缘情况。
有人可以就此事提供一些实用指导吗？
思考：E / C / A或计划任务引擎每隔一段时间醒来，看看此时是否有任何需要运行的计划任务（即下一个运行日期已过，但是到期日期已经过去尚未到达）。
答案 0 :(得分：5)
我们的系统有60台计算机，每台计算机运行12个任务（线程），需要“获得下一份工作”。总而言之，它每天达到50K“工作”。计算每分钟有多少交易并实现任务时间是可变的，因此可以在同一时间获得多个“流行”事件。
我们的第一个版本使用MSMQ。结论：远离。虽然它在加载和同步问题上做得很好，但它有两个问题。一个恼人的和一个交易破坏者。
恼人的：作为企业软件，MSMQ具有安全需求，只需要与客户网络管理员进行设置和对抗。
交易破坏者：然后是我们想要接受下一份工作的时间，但不是使用简单的流行音乐，而是“获得下一个蓝色工作”或“获得下一个黄色工作”。做不到！
我们去了B计划：用一个SQL 2005表实现了我们自己的Q. 不能更开心
我强调每天用200K消息测试它，工作。我们可以使“下一步”逻辑变得像我们想要的那样复杂。
catch：你需要非常小心采用下一个项目的SQL。因为你想要它快速和非锁定。我们根据一些研究使用了2个非常重要的SQL 提示。魔术是这样的：
SELECT TOP 1 @Id = callid
FROM callqtbl WITH (READPAST, XLOCK)
where 1=1 ORDER BY xx,yy
答案 1 :(得分：4)
我已经看到MSMQ在事务上使用并且它似乎并不特别复杂 - 一个事务SCope包装了enqueue或者将调用与数据库访问一起出列，只要队列在创建后被定义为事务性，所有这些都很好。我不认为ActiveMQ是一个消息代理，但是MSMQ是在每个端点机器上本地安装的，因此在事务上将项目放入队列不需要花哨的分布式事务。
你可能已经意识到了这一点，但是在.NET上有一些轻量级的库提供了一些关于MSMQ的很好的抽象（理论上还有其他的传输）
nServiceBus：www.nservicebus.com
公共交通：http://code.google.com/p/masstransit/
此外，Oren Eini有一个有趣的if基于实验文件系统的事务队列。这个库的好处是，与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/
答案 2 :(得分：1)
Quartz.Net是一个开源作业调度系统。
答案 3 :(得分：1)
这就是MSMQ的目的 - 排队交易。如果这对您不起作用，请查看SQL Server的“Service Broker”功能 - 它的“SQL表中的队列”，“csmba”在他的回答中描述，但它是一个集成的SQL Server组件，包装精美并暴露给您使用。
答案 4 :(得分：0)
WebSphere MQ（MQ Series）是一个选项吗？支持事务性消息传递。
答案 5 :(得分：0)
您可以查看名为Advanced Queuing
的Oracle功能