一、组件
二、6种工作模式
HolloWord、WorkQueues、Publish/Subscribe、Routing、Topic、RPC。
2.1、HolloWord模式
该模式不会用到交换机，实际工作场景也不会用到，只是简单的消息的生产和消费。
2.2、WorkQueues 工作队列模式
【说明】：工作队列会发送一些耗时任务给多个工作者（worker）。在多个消息的情况下，Work Queue会将消息分派给不听的消费者，每个消费者都会接收到不同的消息，并且可以根据处理消息的速度来接收消息的数量，进而让消费者程序发挥最大性能。
Work Queue特别适合在集群环境中做异步处理，能最大程度发挥每一台服务器的性能。
【应用场景】：
2.3、Publish/Subscribe 发布/订阅模式
【说明】：该模式中，生产者不再直接与队列绑定，而是将数据发送到交换机（x：Exchange），交换机用于将数据按某种规则送入与之绑定的队列，进而供消费者使用。该模式下，将换季无差别的将所有的消息送入与之绑定的队列，所有消费者拿到的消息完全相同。
【应用场景】：国家气象局发送的天气预报，不同的门户网站订阅天气消息的场景。但是如果北京电视台没有拿到南京的授权，还想获得数据，就不能用该模式，因为发布订阅模式的所有数据都是相同且完整的，而应该用路由模式。
2.4、Routing 路由模式
【说明】：该模式是发布订阅模式的变种，发布订阅是无条件将所有消息发送给所有的消费者。路由模式是交换机根据Routing Key有条件的将数据筛选后发送给消费者队列。
【应用场景】：日志收集。将error的错误日志，打上标记为type=direct，交换机就会将error的数据单独放在特殊队列中，再由独立的消费者消费。比如死信队列。
2.5、Topic 主题模式
【说明】：主题模式是在Routing模式上，提供了对RouteKey模糊匹配的功能，可以简化程序的编写。模糊匹配表达式规则如下：
1、 * 匹配单个关键字
2、 # 匹配所有关键字
路由模式是精准匹配，主题模式是模糊匹配，实际应用中，执行效率肯定是精准匹配效率高，故而实际应用中，能用路由模式，就不要使用主题模式。
【应用场景】：
2.6、RPC 远程调用模式
RPC同步通信
【说明】：实际工作中几乎用不到，因为有太多的专用工具比它做得好，比如Bubbo。
三、MQ消息积压
3.1、最简单的办法：RebbitMQ改为工作队列模式，就是负载均衡，堆机器。
3.2、死信队列
依赖RabbitMQ的死信队列特性，将死信消息自动送达死信队列中，BS前台接收死信消息，1小时候重新发送，等待闲时由信审系统进行处理。如此实现了在不增加资源的前提下，对信审系统资源“削峰填谷”。接受到的死信消息，将保存到死信消息表，1小时候重新发送。
【扩展】：死信队列
死信：过期或无法处理的消息；
死信的产生：
- 消费者拒绝接受，且没有重新入列的消息；
- 队列满了，无法入列的消息；
- 消息设置了TTL过期时间，超过有效时间后的消息；
- 队列设置了TTL过期时间，超过有效时间后的消息。
消息和队列TTL都过期，以谁为准呢？以TTL时间短的为准。
死信队列配置界面，采用路由模式，TTL时间设置为10秒=10000ms
四、集群
RebbitMQ基于Erlang编写，Erlang天生具备分布式特性（通过Erlang集群节点的cookie实现）。RebbitMQ不需要如kafka那样通过Zookeeper来实现HA方案和集群数据持久化。
可以参考：消息中间件—RabbitMQ（集群原理与搭建篇) (qq.com)
标签：队列,模式,死信,RabbitMQ,TTL,路由,消息 From： https://www.cnblogs.com/xiaobaicai12138/p/17853063.html