大家好，如果您还对高效利用RabbitMQ：优秀团队实践经验分享不太了解，没有关系，今天就由本站为大家分享高效利用RabbitMQ：优秀团队实践经验分享的知识，包括的问题都会给大家分析到，还望可以解决大家的问题，下面我们就开始吧！
我大概从2013年开始接触RabbitMQ，到现在已经七年多了。
这七年里，我对RabbitMQ有过一些深入的体会，也有无数的血泪史。
我想将我关于RabbitMQ的经验和见解分为三篇文章：
预开发规范；开发过程中的考虑因素；以及MQ本身的优化。这次我们先从预开发规范开始。
我一直很好奇为什么大家在使用开发语言的时候都有开发规范，在使用数据库的时候都有数据库规范，但是在使用MQ的时候却很少有规范。
缺乏使用MQ 的规范。这是一个常见问题吗？还是这只是我身边的一个案例？
不管答案如何，在使用RabbitMQ时，为了在开发过程中少出现问题，达到事半功倍的效果，需要提前规范一些配置和事项。
1. 一个 RabbitMQ 应用里建立多个 vhost，去对应不同的开发项目当我们使用数据库时，我们会在一个数据库应用程序中创建多个不同的数据库供不同的项目使用，而不是在不同的服务器上为每个项目安装单独的数据库应用程序。
在RabbitMQ的vhost中，也有类似的概念。
虚拟主机本质上是RabbitMQ 服务器的迷你版本，具有自己的队列、绑定、交换机和权限控制。在RabbitMQ 中创建用户时，该用户通常会被分配到至少一个虚拟主机，并且只能访问分配的虚拟主机内的队列、交换机和绑定，彼此之间是绝对隔离的。
因此，不同的vhost对应不同的项目，互不影响。事实上，这些虚拟主机都位于一台主机和一个RabbitMQ 应用程序上。
然而目前的情况是，大多数使用RabbitMQ的技术团队经常使用默认的vhost：“/”。如果有额外的项目，他们将创建一个RabbitMQ 进程。这样做是对开发资源的巨大浪费。
建议1个项目对应1个vhost。
2. 不直接使用 RabbitMQ 自己的客户端很多使用RabbitMQ的公司直接使用RabbitMQ自带的java版客户端。但由于RabbitMQ本身固有的复杂性和多样性，有很多技术细节需要单独处理。
比如网络连接处理、异常处理、消息失败处理等，如果手头没有一个成熟的框架，很可能有些细节处理不好，从而导致很多问题，这些都是不必要的费用。
因此，要么使用现有的RabbitMQ客户端框架（比如Spring的RabbitMQ框架），要么自己封装一套底层RabbitMQ客户端框架，而不是单独使用RabbitMQ客户端。
3. 无论如何消费者必须给回 ACK 响应ACK机制是消费者收到RabbitMQ发来的消息并完成处理后反馈给RabbitMQ，然后RabbitMQ收到反馈后从队列中删除该消息。
由于ACK机制本身必须回复RabbitMQ，因此消息会因为这个特性而被丢弃。关于什么时候给ACK，我们开发的时候一定要在开发项目之前提前规划设计。
当我们使用RabbitMQ时，我们通常不希望在收到消息后立即发回ACK，并且我们不会设置autoACK机制来在消费者收到消息时自动返回ACK响应。一般来说，我们会根据不同的业务逻辑，在不同的位置手动返回ACK。
这时候可能会出现问题：当收到消息时，有时业务逻辑会报错，而业务逻辑处理完后往往会忽略ACK，从而导致消息始终卡在队列中。如果数量越来越多的话，后续的处理就很麻烦了。
4. 考虑设置 dead letter exchanges为什么那么多人不设立死信交换？这是我非常困惑的事情。
我出去使用RabbitMQ与各个项目团队进行交流，发现很少有人建立死信交换。这是有问题的。
我们必须知道，有时消息传递出错时，并不总是在应用程序接收时发生。有很多非应用问题。例如：
消费者端出现问题，发送的消息被拒绝。并且我们还设置了requeue=false；
消息可能因为没有收到ACK而消息超时而被删除，或者消费端跟不上消费速度，导致消息超时被删除；
消息数量超过队列最大长度限制，被丢弃；
消息总大小超过队列消息总大小限制并被丢弃。
对于这些问题，设置死信交换是一个解决方案。
一旦消息出现我上面列出的情况，它就会被发送到我们设置的死信交易所。然后我们可以单独处理这些特殊情况消息，这可以使我们的项目更加健壮，并且更容易跟踪问题。
5. 尽量使用 Direct ExchangeRabbitMQ的Exchange是消息交换器，它指定了按照哪些规则将消息路由到哪个队列。
这种人有四种类型：
主题：将路由键与特定模式进行匹配。这时候就需要给队列绑定一个模式。符号“#”匹配一个或多个单词，符号“*”只能匹配一个单词。
Fanout：不处理路由键。您只需将队列绑定到交换机即可。发送到此类交换机的消息将广播到绑定到该交换机的所有队列。
headers：不处理routing key，而是根据发送的消息内容中的headers属性进行匹配。绑定Queue和Exchange时指定一组键值对；当消息发送到RabbitMQ时，会获取消息的头部并与绑定Exchange时指定的键值对进行匹配；如果完全匹配，则消息将被路由到队列，否则不会被路由到队列。
在这四种类型中，Direct 类型的Exchange 传递消息的速度最快。对于其他交易所，MQ仍然要花时间计算交付地点。
因此，如果可以使用Direct类型，建议使用Direct。
强烈建议大家在团队中使用之前先准备一份规范。否则，如果很多程序员很随意地使用RabbitMQ，很容易导致各种问题。
下一篇我会写一些开发过程中需要注意的事情。
虽然是开发过程中需要注意的事情，但实际上是我在开发成熟的RabbitMQ客户端框架时遇到的各种问题的总结。如果有些读者恰好所在的开发团队有类似的经历，那么你会发现你可能会遇到我提到的所有问题。
本文采摘于网络，不代表本站立场，转载联系作者并注明出处：https://www.iotsj.com//kuaixun/6811.html
用户评论
想了解一下别人家的经验，看看怎么用RabbitMQ更好地管理任务队列。
有8位网友表示赞同！
学习别人的规范，希望能提高我们项目的开发效率和稳定性。
有10位网友表示赞同！
这篇文章很有帮助，可以让我们避开一些常见的问题。
有19位网友表示赞同！
分享51CTO的文章真是太好了！期待看到具体的例子和实施方案。
有14位网友表示赞同！
RabbitMQ的使用确实很灵活，学习别人的规范能帮我们更好地利用它的功能。
有20位网友表示赞同！
对于大型团队来说，规范的重要性更高，这篇文章恰如其分。
有9位网友表示赞同！
关注一下别人家的经验，也许可以为我们的项目提供一些新的思路。
有13位网友表示赞同！
看了标题就感觉很不错，一定会对我们提升代码质量有所帮助。
有6位网友表示赞同！
RabbitMQ在高并发场景很有用，看看怎么规范使用它是个好主意！
有14位网友表示赞同！
希望这篇文章能介绍一些比较实用的最佳实践，让我在项目中更好地应用RabbitMQ。
有10位网友表示赞同！
了解一下其他团队的思路，可以让我们避免走弯路。
有16位网友表示赞同！
5点规范听起来很有吸引力，希望能详细说明每个规范的内容和作用。
有7位网友表示赞同！
作为一名开发人员，学习优秀经验非常重要，这篇文章对我来说很值。
有11位网友表示赞同！
RabbitMQ的应用场景很多样，关注别人家的做法能帮助我们拓宽视野。
有9位网友表示赞同！
希望这篇文章能提供一些具体的指导和案例分析，让我们更好地理解RabbitMQ规范的意义。
有9位网友表示赞同！
对于团队合作来说，有规范非常必要，这篇文章值得一读！
有16位网友表示赞同！
我一直在学习RabbitMQ的使用方法，希望能从这篇文中找到实用的技巧。
有18位网友表示赞同！
分享经验很重要，期待看到文章中的具体案例和分析。
有16位网友表示赞同！
别人家的成功经验可以借鉴很多，看看他们是如何规范使用RabbitMQ的。
有15位网友表示赞同！