我正在我的宠物项目中使用RabbitMQ（基于Spring Boot）。在@Configuration中，我声明了Queue、Binding、DirectExchange等bean。因此，当我运行这个应用程序时，所有这些交换和与队列的绑定都是自动创建的。我应该在应用程序启动之前将其分成单独的步骤吗？例如，在应用程序启动之前，调用一系列curl到管理HTTP API来创建所有需要的队列（带有交换和绑定）。创建/配置路由相关内容的最佳实践是什么？
@Configuration
Queue
Binding
DirectExchange
curl
ryhaxcpt1#
问题是RabbitMQ没有唯一的使用方法。但是在与任何经纪人合作之前，我总是问自己几个问题。我将把它们应用到你的问题中。
让我们质疑这种方法
试着了解你所使用的元素是否持久。如果是，那么你可以在启动时在你的代码中创建它，并应用一个简单的健康检查。你还想检查你的RabbitMQ服务器是否持久化数据。如果不是，那么你就必须每次都创建你的队列，交换和绑定。
您需要考虑两个主要问题1.延迟有多重要？如果延迟确实很重要，请尽可能多地使用直接交换。原因很简单。您只是从交换到队列，而不是必须路由您的消息。路由会增加延迟，请不要忘记！如果这几个额外的毫秒对您没有影响，则需要记住以下问题，以了解如何定义您的交换、绑定和队列。1.我将如何使用我的经纪人？有些人使用他们的代理来简单地发布/订阅消息。这是一个非常合理的用例。在这种情况下，扇出交换将是最可行的选择。如果你试图最小化队列的数量，你正在创建一个主题交换可能是有趣的。然而，更重要的是，您是将代理专门用于服务间通信，还是您的服务将既是生产者又是消费者？见鬼，这是前两种情况的混合体吗？需要明确定义此边界。否则，您将陷入混乱，您会突然发现您正在使用的消息实际上可以由另一个库在内部处理，或者只是将参数传递给函数。
应用方法示例：
案例：我们有一个日志服务&用户服务：
在服务通信之间。
| 交易所名称|交换类型|装订|队列|| - -|- -|- -|- -|| 使用者|题目|使用者指令 *| 用户：crud|| 使用者|题目| user.event.login |用户：登录|从上面可以清楚地看到，我们可以使用一个简单的队列来处理所有的CRUD操作。这是最有效的方法吗？这取决于您的服务。user.cmd.create应该转到user:created可能更好。这是您需要定义的另一个边界。还有一点需要提到的是，你应该把你的队列和路由关键字作为信息片段来使用。调试一个微服务可能是地狱般的。所以应用一个通用的命名约定将是最合适的。没有一个命名约定，所以这再次取决于你的用例。
user.cmd.create
user:created
结论：
一般来说，对于任何代理来说，最好的做法是明确定义代理的范围及其底层元素。如果做得不好，启动时是否进行健康检查并不重要。很容易迷失在rabbitMQ提供的复杂性和有趣的特性中。一开始尽量让它保持简单，并问问自己：“这会花费我大量的时间来重构/调试/修复吗？”如果答案是肯定的，请返回到本段的第一句。
文件：
AMQP概念：https://www.rabbitmq.com/tutorials/amqp-concepts.html一些通用最佳实践：https://www.cloudamqp.com/blog/part2-rabbitmq-best-practice-for-high-performance.html工艺路线：https://www.rabbitmq.com/tutorials/tutorial-four-python.html延迟和吞吐量：https://blog.rabbitmq.com/posts/2012/05/some-queuing-theory-throughput-latency-and-bandwidth
1条答案
按热度按时间ryhaxcpt1#
问题是RabbitMQ没有唯一的使用方法。但是在与任何经纪人合作之前，我总是问自己几个问题。我将把它们应用到你的问题中。
让我们质疑这种方法
试着了解你所使用的元素是否持久。如果是，那么你可以在启动时在你的代码中创建它，并应用一个简单的健康检查。你还想检查你的RabbitMQ服务器是否持久化数据。如果不是，那么你就必须每次都创建你的队列，交换和绑定。
您需要考虑两个主要问题
1.延迟有多重要？
如果延迟确实很重要，请尽可能多地使用直接交换。原因很简单。您只是从交换到队列，而不是必须路由您的消息。路由会增加延迟，请不要忘记！如果这几个额外的毫秒对您没有影响，则需要记住以下问题，以了解如何定义您的交换、绑定和队列。
1.我将如何使用我的经纪人？
有些人使用他们的代理来简单地发布/订阅消息。这是一个非常合理的用例。在这种情况下，扇出交换将是最可行的选择。如果你试图最小化队列的数量，你正在创建一个主题交换可能是有趣的。
然而，更重要的是，您是将代理专门用于服务间通信，还是您的服务将既是生产者又是消费者？见鬼，这是前两种情况的混合体吗？需要明确定义此边界。否则，您将陷入混乱，您会突然发现您正在使用的消息实际上可以由另一个库在内部处理，或者只是将参数传递给函数。
应用方法示例：
案例：我们有一个日志服务&用户服务：
在服务通信之间。
| 交易所名称|交换类型|装订|队列|
| - -|- -|- -|- -|
| 使用者|题目|使用者指令 *| 用户：crud|
| 使用者|题目| user.event.login |用户：登录|
从上面可以清楚地看到，我们可以使用一个简单的队列来处理所有的CRUD操作。这是最有效的方法吗？这取决于您的服务。
user.cmd.create应该转到user:created可能更好。这是您需要定义的另一个边界。还有一点需要提到的是，你应该把你的队列和路由关键字作为信息片段来使用。调试一个微服务可能是地狱般的。所以应用一个通用的命名约定将是最合适的。没有一个命名约定，所以这再次取决于你的用例。
结论：
一般来说，对于任何代理来说，最好的做法是明确定义代理的范围及其底层元素。如果做得不好，启动时是否进行健康检查并不重要。很容易迷失在rabbitMQ提供的复杂性和有趣的特性中。一开始尽量让它保持简单，并问问自己：“这会花费我大量的时间来重构/调试/修复吗？”如果答案是肯定的，请返回到本段的第一句。
文件：
AMQP概念：https://www.rabbitmq.com/tutorials/amqp-concepts.html
一些通用最佳实践：https://www.cloudamqp.com/blog/part2-rabbitmq-best-practice-for-high-performance.html
工艺路线：https://www.rabbitmq.com/tutorials/tutorial-four-python.html
延迟和吞吐量：https://blog.rabbitmq.com/posts/2012/05/some-queuing-theory-throughput-latency-and-bandwidth