RPC框架调用过程

我们得知道，有时候消息投递出错，并不总是在应用接收的时候出了问题，会有很多非应用的问题。比如：

消费端有问题，发出的消息被拒绝了。并且我们也设置了 requeue=false;

消息可能因为没有收到 ACK 超时被删除，或者消费端消费速度跟不上导致消息超时被删除;

消息数量超过了队列最大长度限制被抛弃;

消息总大小超过了队列消息总大小限制被抛弃。

对于这些问题，设置 dead letter exchanges 算是一个解决办法。

当消息一旦出现我上面列举出来的情况，就会被发送到我们设置的 dead letter exchanges。然后我们就可以对这些特殊情况的消息进行单独处理，这样的做法可以让我们的项目更健壮，更容易追踪问题。

5. 尽量使用 Direct Exchange

RabbitMQ 的Exchange 就是消息交换机，它指定消息按什么规则，路由到哪个队列。

这家伙有四种类型：

Direct：处理路由键，需要将一个队列绑定到交换机上，要求该消息与一个特定的路由键完全匹配。这是一个完整的匹配。如果一个队列绑定到该交换机上要求路由键为“green”，则只有路由键为“green”的消息才被转发，不会转发路由键为"red"，只会转发路由键为“green”。

Topic：将路由键和某模式进行匹配。此时队列需要绑定要一个模式上。符号“#”匹配一个或多个词，符号“*”只能匹配一个词。

Fanout：不处理路由键。你只需要简单的将队列绑定到交换机上。一个发送到该类型交换机的消息都会被广播到与该交换机绑定的所有队列上。

Headers：不处理路由键，而是根据发送的消息内容中的 headers 属性进行匹配。在绑定 Queue 与 Exchange 时指定一组键值对;当消息发送到 RabbitMQ 时会取到该消息的 headers 与 Exchange 绑定时指定的键值对进行匹配;如果完全匹配则消息会路由到该队列，否则不会路由到该队列。

在这四种类型里，Direct 类型的 Exchange 投递消息是最快的。其他的 Exchange，MQ 还得花时间计算投递的位置。

所以，能使用 Direct 类型的建议使用 Direct。

以上就是在使用 RabbitMQ 前，需要考虑使用的规范，有了这些规范，很多程序员就能据此写出比较稳定健壮的程序，而不会导致各种莫名其妙的问题。

强烈建议大家在团队使用之前，先弄一份规范。否则，如果很多程序员使用 RabbitMQ 非常随意，容易导致出现各种幺蛾子问题。

在下一篇文章里，我将写一些开发中需要注意的事项。

虽说是开发需要注意的事项，其实就是我在开发一套成熟的 RabbitMQ 客户端框架时，碰到的各种问题的总结。如果有些读者所在的开发团队恰好也有类似的经历，那么我说的所有问题，你会发现你可能都会遇到。