【问题标题】:Design suggestion for RabbitmQ Producer & Consumer [closed]RabbitmQ Producer & Consumer 的设计建议 [关闭]
【发布时间】:2021-01-31 12:06:40
【问题描述】:

我有一个 RabbitMQ 设计问题。假设我有 6 个交换和 10 个队列,并按如下方式划分

  • 5 个“扇出”类型的交换,并绑定了 5 个队列
  • 1 个“主题”类型的交换,并根据路由键被路由到 5 个不同的队列。

我有一个运行 Kubernetes 规模为 25 的微服务应用程序,所有这些应用程序每个进程获取 1 个 rabbitmq 连接。所以 25 个 rabbitmq 连接充当生产者。

我有另一个应用程序也在 Kubernetes 中运行,规模为 1,这些应用程序获取 1 个 rabbitmq 连接。所以 1 个 rabbitmq 连接充当消费者。

数字:假设每个交易所每天收到 10 万条消息。

技术栈:Node.js + amqplib

问题:

  1. 生产者需要创建多少个通道才能将消息发布到交易所?
  2. 消费者需要创建多少个通道来消费队列中的消息?
  3. 让一个应用程序充当消费者来使用所有队列中的消息是一种好方法吗?
  4. 如何根据 Kubernetes 中的队列大小自动扩展消费者?
  5. 是否可以根据消费者建立优先级?假设由于负载过重,我希望消费者停止从几个队列中消费,并将所有资源集中在其余队列上。
  6. 生产者和消费者应该创建多少个连接?

提前致谢:)

【问题讨论】:

    标签: node.js kubernetes design-patterns rabbitmq


    【解决方案1】:

    从语义上讲,您的系统中会有发布和消费组件。每个人都应该使用一个频道,主要是因为error reporting and handling is channel-scoped。

    单个应用程序是否应该从“所有”队列中消费,完全取决于您如何构建服务。

    控制消费者从哪些队列中消费的内容也是如此。通常队列和消费者具有语义“类型”并服务于特定目的。

    只需添加更多消费者,increasing prefetch 只会在一定程度上起作用,单个队列有一个 realistic throughput limit。

    根据队列长度(特别是就绪状态的消息)扩展应用程序实例涉及监控各个队列指标。只有works with a small number of queues(例如 100K 队列从所有队列中收集所有指标变得非常昂贵)。

    一个小型应用程序应该可以监控单个队列的指标或总数,并使用 Kubernetes API 更新部署中应用程序的副本数量。

    【讨论】:

      猜你喜欢
      • 2016-09-07
      • 2021-03-01
      • 2021-04-26
      • 1970-01-01
      • 2013-12-12
      • 1970-01-01
      • 2013-05-29
      • 2012-04-20
      • 2010-09-19
      相关资源
      最近更新 更多