问题标签 [message-bus]

在我们的应用程序中，发布者创建一条消息并将其发送到一个主题。

然后它需要等待，当所有主题的订阅者都确认消息时。

它不会出现，消息总线实现可以自动执行此操作。因此，我们倾向于让每个订阅者在完成后向客户发送他们自己的新消息。

现在，客户端可以接收所有此类消息，并且当它从每个目的地收到一条消息时，就可以进行任何它必须做的清理工作。但是，如果客户端（发送方）在确认流中途崩溃了怎么办？为了处理这样的不幸，我需要在客户端（重新）实现总线已经实现的东西——保存传入的确认，直到我得到足够的确认。

我不相信，我们的需求是如此深奥——您将如何处理这种情况，发件人（发布者）必须等待来自多个收件人（订阅者）的确认？有点像从每个订阅者向邮件列表请求（和等待）回执......

如果重要的话，我们正在使用 RabbitMQ。谢谢！

我在 Membus 中看到了 IoC 功能，我尝试将其连接到 Simple Injector

这个想法是我将自动注册我的所有类型RegisterManyForOpenGeneric(typeof<CommandHandler<>),typeof<CommandHandler<>).Assembly)。

毫无疑问，通常有充分的理由，SimpleInjector 不允许多次注册 - 但是，我想这样做是为了让不同的处理程序实现命令处理的不同方面/问题。

当然，IEnumerable<object> IocAdapter.GetAllInstances(Type desiredType)来自 membus 的接口需要一个集合，因此可以调用多个处理程序。

将 Membus 与 SimpleInjector IoC 结合的最佳方式是什么？

脚注

我已经看到了按照惯例连接menbus的其他方法：

但我真的很想坚持使用 IoC 容器来处理生命周期范围，并避免实例化命令处理程序并在需要它们之前手动连接它们。

我们有一个与第三方网络服务对话的 Rebus 消息处理程序。由于我们无法直接控制的原因，此 WCF 服务经常抛出异常，因为它在自己的数据库中遇到了数据库死锁。然后 Rebus 将尝试处理此消息五次，这在大多数情况下意味着这五次中的一次将是幸运的并且不会陷入僵局。但是经常发生消息在死锁之后确实会死锁并最终进入我们的错误队列。

除了解决死锁的根源（这将是一个长期目标）之外，我还可以想到两个选择：

1. 继续尝试仅使用此特定消息类型，直到成功。最好我可以设置一个超时，所以“如果有五个死锁，然后在 5 分钟内再试一次”，而不是通过连续尝试进一步阻塞进程。我已经做了一个 Thread.Sleep(random) 来传播消息，但它仍然会在五次尝试后放弃。

2. 将此特定消息类型发送到一个不同的队列，该队列只有一个处理消息的工作人员，因此这是串行发生的，而不是并行发生的。我们当前的配置使用 8 个工作线程，但这只会使死锁情况变得更糟，因为 Web 服务现在被并发调用并且消息相互干扰。

选项#2 有我的偏好，但我不确定这是否可行。我们在接收端的配置目前如下所示：

接收方的 .config ：

从配置中我可以看出，只能将一个输入队列设置为“收听”。我也无法通过流畅的映射 API 找到一种方法。这似乎也只需要一个输入和错误队列：

基本上，我正在寻找的是类似的东西：

关于如何处理我的要求的任何提示？

我在使用消息总线时遇到问题，希望您能帮助我。

我有 2 个 portlet

在 portlet 1 中，一个 regiostr 所有的列表器和目的地

一切正常，当我从 Portlet 1 发送消息时，同一个 Portlet 中的所有侦听器都会被执行。

但我不明白如何在 portlet 2 中的同一消息上注册 Listner？

希望sameone可以帮助我。

马可

我正在测试 ZeroMQ 作为中型系统的 Pub-Sub（服务总线样式）基础设施。我们大约有 50 个节点，它们都应该是发布者和订阅者。网络是一种星型拓扑，但边缘相互“对话”。我们需要动态发现（无需对参与者的网络地址进行硬编码），但也不需要 SPOF（单点故障）。

我已阅读http://zeromq.org/whitepapers:0mq-3-0-pubsub并且据我了解，建议的 0MQ 动态发现方式涉及转发订阅和发布的代理节点 (XPUB/XSUB)。我考虑在我们的系统中使用这样的代理作为中央调解器，但是，我对这种架构有以下担忧：（A）代理节点是 SPOF - 当它失败时，整个系统无法运行（B）所有流量，包括数据，通过代理节点，这意味着延迟和性能问题。

假设我正确理解了 pub-sub 白皮书，是否有一种相对简单的方法可以在 ZeroMQ 中实现 pub-sub + dynamic-discovery + no-SPOF？

附加点：我已经排除了多播（PGM）解决方案，因为大多数消息都有一个/几个感兴趣的方，我们不喜欢过度拥挤网络。

需要有关如何从在 Z/OS 上运行的 Message Broker V7.0 从 SQL Server 2012 数据库中提取和更新数据的输入。我们最初考虑使用 MB 的数据库输入节点。但是根据 IBM 7.0 信息中心 ( http://publib.boulder.ibm.com/infocenter/wmbhelp/v7r0m0/index.jsp?topic=/com)，z/OS上的 MB 7 似乎不支持 SQL Server 。 ibm.etools.mft.doc/ah10030_.htm），是否必须有一些自定义代码/自定义节点才能连接到 SQL Server？

任何有关此主题的想法将不胜感激。

我试图澄清亚马逊的 SQS 死信队列到底在做什么。

根据http://aws.typepad.com/aws/2014/01/amazon-sqs-new-dead-letter-queue.html

死信队列- SQS 队列的 ARN（Amazon 资源名称），将接收在消费者接收到最大数量后未成功处理的消息。

这听起来不是更像毒药队列吗？关键区别在于消费者确实收到了消息。死信是指消息可能很好，但可能由于服务中断而无法传递。http://www.eaipatterns.com/DeadLetterChannel.html

这听起来像是多次成功接收消息，但处理消息失败，我理解这是毒消息队列的含义。

消息总线与队列

死信模式在普通旧队列的上下文中是否具有不同的含义？由于 SQS 只是一个队列，而不是消息总线，因此它不负责传递消息。相反，它等待消息被拾取（请求）。所以传统的死信模式并不真正适用，因为没有消息总线试图传递消息并且无法找到接收者。

SQS 可以像消息总线一样工作吗？

有没有办法通过 SQS 设置通道和侦听器，而不是显式轮询队列中的消息？

我有一个定价应用程序。它将定价请求发送到 Azure 服务总线队列（可以是任何队列）“PricingRequestQueue”。有许多工作人员负责收集、处理它们并将结果返回到 PricingResponse Queue。

我想在 PricingResponse 队列上创建一个 Observable。我不需要任何过滤，但想使用批处理接口 (QueueClient.BeginReceiveBatch) 读取消息。队列具有预期的消息数量，并且有一个要从中读取的会话 (QueueClient.AcceptMessageSession(correlationIdentifier)。

我仍在努力让我的头脑围绕 RX，这真的会让事情变得清晰。

我正在将不同的有界上下文与 Windows 服务总线集成并有一些问题：

1）如何在其他有界上下文中检测重复？存储最后处理的消息序列？我希望能够重新触发事件以允许重新同步新的有界上下文HandleEvent(OrderPlaced orderPlaced, bool isReplay)，这些上下文在未来被购买到生产中以进行初始同步。

2) 对于上下文间消息总线，我们是否会为每个有界上下文使用一个主题（并使用命名空间来对有界上下文进行分组）？还是每个命名空间有一个有界上下文？

3）消息总线文档说消息可以乱序到达，应该使用什么算法来按顺序重新组装？如果收到了消息 6 和 8，但没有收到消息 7，会发生什么？我们会等待指定的时间，然后继续吗？如何允许自我修复？

4）我想以上在几乎所有 DDD 项目中都很常见，是否有任何库可以处理包括命令/响应协议在内的消息传递，以从外部有界上下文请求同步先前事件？

我在 Xamarin 中构建一个播放音乐的 Android 应用程序。我有一个播放音乐的服务和一个显示播放列表的片段，有时我想从服务中得到一个小的反馈，到目前为止我一直在使用MessageBus进行通信。

目前我唯一需要反馈的时候是当用户选择循环整个列表并且当前曲目完成时我需要通知片段是下一个曲目以突出显示它。也许将来我需要反馈。

这是一个坏主意吗？我应该更好地使用 boundService 更改服务？我选择了这种方法，因为它更简单，而且我想要的反馈非常有限，但现在我有了第二个想法。谢谢