使用NServiceBus或MassTransit的服务总线的故障转移很有意义

我需要构建像Microsoft的http://login.live.com这样的身份服务器.

要处理故障转移,我将拥有多个Web服务器节点.计划是通过向数据库服务器发送消息来完成所有数据库写入操作.数据库将被镜像或复制.这个想法是数据库订阅写操作,但其他节点也订阅.这样,其他节点不需要从数据库读取并可以更新其缓存.

我刚刚开始学习服务总线架构,我不清楚如何处理服务总线的故障转移场景.

题:

如果数据库服务器不可用,发布的消息会发生什么？

它们会存放在某个地方吗？

我是否需要额外的机器或群集来处理服务总线的故障转移？

我读过SQL Server可以用作消息存储但是我可以使用持久的MSMQ吗？我正在排队消息以便能够将它们写入数据库,那么我为什么要先将它们存储到数据库中,然后将它们再次写入？或者,我错了,DB仅用于订阅列表而不用于消息？

Travis.. 8

这将取决于它的设置方式,但在MassTransit中,您可以使订阅处于活动状态,以便仍然可以将消息传递到数据库的队列.当DB再次处于活动状态时,您可以读取队列中的消息.

连接到服务总线的每个服务(在MassTransit中)都有一个活动队列.消息将存储在那里.

我认为这是"它依赖"...... MassTransit支持其他MQ而不是MSMQ,但实际上是围绕MSMQ构建的.我们没有经验丰富的支持,例如来自MSMQ的故障转移.但是,如果订阅服务(即总线)失败,一切都将继续无故障运行 - 服务已经知道与谁交谈.只有在消费者(订阅或取消订阅)发生变化时才会出现问题.对我来说,这是一个几乎从未发生过的事件.

使用MassTransit,我们使用DB来存储订阅状态,但所有消息都存储在MSMQ中.

如果您想了解其中一个回复中的详细信息或有关于MT的其他问题,可以加入我们的邮件列表:http://groups.google.com/group/masstransit-discuss.

这将取决于它的设置方式,但在MassTransit中,您可以使订阅处于活动状态,以便仍然可以将消息传递到数据库的队列.当DB再次处于活动状态时,您可以读取队列中的消息.

连接到服务总线的每个服务(在MassTransit中)都有一个活动队列.消息将存储在那里.

我认为这是"它依赖"...... MassTransit支持其他MQ而不是MSMQ,但实际上是围绕MSMQ构建的.我们没有经验丰富的支持,例如来自MSMQ的故障转移.但是,如果订阅服务(即总线)失败,一切都将继续无故障运行 - 服务已经知道与谁交谈.只有在消费者(订阅或取消订阅)发生变化时才会出现问题.对我来说,这是一个几乎从未发生过的事件.

使用MassTransit,我们使用DB来存储订阅状态,但所有消息都存储在MSMQ中.

如果您想了解其中一个回复中的详细信息或有关于MT的其他问题,可以加入我们的邮件列表:http://groups.google.com/group/masstransit-discuss.

在实现这种架构时,您应该考虑应用CQRS的原则 - 查询(此用户/ pwd组合有效)不应通过总线完成; 命令(更改pwd,忘记密码)通过总线发送,不作为事件发布.在内部,您可能会使用事件来使命令和查询方保持同步,这不涉及客户端.

可以使用简单的ado.net对数据库的复制读取从属进行查询 - 即CQRS中的持久视图模型.如果你愿意,你也可以在它面前放一些简单的WCF.

使用MSMQ时,所有消息都通过存储转发传递.这意味着它们在被传送到服务器之前首先存储在客户端上,因此如果服务器关闭,则消息将在客户端等待.对于容错,您将希望您的消息可以恢复(写入磁盘) - 这是NServiceBus中的默认值,但不是默认的标准MSMQ(不了解MassTransit).您不需要数据库.

在NServiceBus中,总线没有安装在单独的机器上,因此您无需独立于系统的其余部分处理其可用性.只有当您考虑将您的命令处理扩展到更多节点时,才可以考虑使用NServiceBus中的基于消息的负载均衡器(称为分发器),为了实现高可用性,应将其安装在集群或容错硬件上.