我想开发一个连接到某些输入源并处理它读取的消息的应用程序（原则上认为是BizTalk，但不是很重）。为了提高性能和可靠性，我希望能够启用服务的水平扩展，显然可以通过利用共享存储（例如DB）充当消息排队机制。
但是，无法水平扩展访问电子邮件或磁盘文件夹等资源的线程。从该输入源读取时，一次只能运行一个实例。 （进一步的消息处理业务逻辑当然可以驻留在多个节点上）。
这是主动/被动群集的理想选择。一个节点被认为是“活动”并且主动连接到“单实例”资源（例如电子邮件收件箱），而其他节点是“被动”。如果“活动”节点死亡，则其他“被动”节点在它们之间选择一个新的“活动”节点。
现在的问题是：那里有一个.NET库可以帮助人们实现通常的故障转移群集逻辑吗？ （即，实现必要的心跳发送/检测，以及“活动”节点选举过程）。因为我不想重新发明轮子。
我从已经完成的研究中可以看到：
据我所知，它可能被认为是先进的和理想的功能，因此它的商业解决方案价格昂贵。这很好 - 如果没有开源实现或库，我会自己开发一个。我只是不想花费已经存在的努力。
更新12/02/2011：找到SAForum（http://www.saforum.org/link/linkshow.asp?link_id=214720），这是一个发布开放服务可用性概念规范的网站。还有OpenSAF（http://www.opensaf.org/Welcome-to-OpenSAF%E2%84%A2~151213~14944.htm），以及SAForum规范的开源C ++实现。看起来很全面，但非常沉重。我需要花费大量时间来完成规范和文档。它还涵盖了不仅仅是故障转移，为完全可扩展的分布式系统（通知，分布式事件，锁，集群管理等）提供规范......在任何地方仍然没有.NET实现的迹象。
答案 0 :(得分：2)
当然，自己开发这种高级功能比购买它更昂贵。除非您的时间被捐赠给项目，并且没有截止日期，否则我将排除自己写这篇文章。
要获得高可用性和水平扩展，您需要编写 lot 代码。测试它的工作能力达到高可用性生产环境所需的水平也需要相当大的努力。即使你做了所有这些，你是否相信你自己的代码而不是微软的代码，这些代码已经在gazilions中积累了运行时间，并且已经通过所有软件需要经历的多个版本才能变得成熟和稳定。
我知道你真的在询问开源库，但是同样的论点适用 - 你会信任吗，它是经过充分测试的，它是经过现场验证的吗？当它崩溃时你能踢出什么？
更新：这是几年前的事情，我想我已经软化了我对这种关键任务基础设施使用开源的可行性的态度，尽管我仍然认为有商业支持是必不可少的，我仍然会避免自己写。
我会为Rabbit MQ添加一个插件作为高可用性，高度可扩展的消息总线，以便其他人阅读此内容。提供商业支持，并基于开放标准（AMQP）。客户端库几乎适用于任何主要平台。