每个事件生产者一个主题与跨多个生产者共享一个主题消息体系结构
这是一个一般性问题，因为它不仅适用于我的场景（使用Azure服务总线），而且适用于带有事件的发布/订阅html" target="_blank">服务器上下文中的任何事件总线。
- 主题是一对多通信的输出框（我将其解释为一个事件发布者，多个订阅者）
- 主题可以处理不同类型的事件消息，只要它们在某种程度上是相关的（当然，这是非常相关的）
- 在DDD中，有一个有界上下文的概念，我喜欢将微服务/模块作为实现这些有界上下文的一种方式。因此，即使其他一些服务“认为”他们想发布一些相关的内容，并且想访问一个共享的主题来发布，我也认为他们属于一个不同的有界上下文，他们应该有自己的主题。
- 如果多个生产者确实属于同一个有界上下文，那么我认为只有一个服务（或infra模块）应该负责发布在有界上下文中发生的事件。
- 生产者可能也想从其他生产者（它也是订阅者）消费事件。如果一个生产者订阅了同一个主题，并且必须根据消息是自己制作的还是其他人制作的来区分它们，这是没有意义的。
正如您所看到的，从DDD的观点来看，多个需要在同一主题中发布的生产者将触发设计气味。我不是说不能这样做，我是想从技术的角度来看，是否应该避免这样做。
有经验的吗？
共有1个答案
再补充几个我认为我们应该尽可能多地为每个制作人使用一个主题的理由：
- 如果多个生产者将同一事件发布到同一主题，则没有明确的事件所有权和权限。这与您在有界上下文中的观点类似。
- 当多个生产者发布同一事件时，它会在这些生产者之间创建事件模式的耦合。现在，如果不同时影响所有生产者，就无法演化事件模式。这些生产者可以使用事件模式版本控制，但当多个生产者更新相同的事件模式（并生成不同版本的事件模式）时，仍然存在争用
-
我有三根线。线程1(T1)是生成器，它生成数据。线程2和线程3(T2和T3)分别等待T1的数据在单独的循环中处理。我正在考虑在线程之间共享BlockingQueue,并通过调用“Take”让T2和T3等待。
-
我有一个生产者/消费者场景，我不希望一个生产者交付产品，多个消费者消费这些产品。然而，常见的情况是，交付的产品只被一个消费者消费，而其他消费者从未看到过这个特定的产品。我不想实现的是，一个产品被每个消费者消费一次，而没有任何形式的阻碍。 我的第一个想法是使用多个BlockingQueue，每个消费者使用一个，并使生产者将每个产品按顺序放入所有可用的BlockingQueues中。但是，如果其中一个
-
我只是在探索，目前我正在使用One
-
我有一个使用ActiveMQ的消息队列。web请求用persistency=true将消息放入队列。现在，我有两个消费者，它们都作为单独的会话连接到这个队列。使用者1总是确认消息，但使用者2从不这样做。 JMS队列实现负载平衡器语义。一条消息将被一个使用者接收。如果在发送消息时没有可用的使用者，它将被保留，直到有可以处理消息的使用者可用为止。如果使用者接收到一条消息，但在关闭之前没有确认它，那么该
-
这里的一些配置：非持久消费者、非持久消息、禁用的流控制、默认预取大小、优化确认=true、异步发送=true、使用jms连接ActiveMQ 例如 一个生产者、一个消费者， 生产者发送速率可以达到6k/s 但是，在这种情况下:一个生产者三个消费者， 生产者发送速率下降到4k/s 这是我的一些关键代码： 发件人类别: sendmain方法： 接收机类代码： 接收器类代码在这里隐藏了一些方法，例如创建
-
问题内容： 因此，我已经看到了许多在Go中实现一个消费者和许多生产者的方法-Go 并发中的经典fanIn函数。 我想要的是fanOut功能。它以一个通道作为参数，它从中读取一个值，并返回一个通道片，该通道将这个值的副本写入其中。 有没有正确/推荐的方法来实现这一目标？ 问题答案： 您几乎描述了执行此操作的最佳方法，但这是执行此操作的一小段代码示例。 去游乐场：https : //play.gola