rabbitmq工作模式介绍

前言：
rabbitmq最新的工作方式有7种 （3.8.9版本），以下展开介绍（翻译）。
一、从AMQP0-9-1说起
https://www.rabbitmq.com/tutorials/amqp-concepts.html
什么是AMQP0-9-1
AMQP 0-9-1 (Advanced Message Queuing Protocol) is a messaging protocol that enables conforming client applications to communicate with conforming messaging middleware brokers.
看下这个图就好了，AMQP0-9-1就是一个高级消息队列的协议，协议里规定了几个部件及要求

image.png

如图，消息发布者发布消息 先经过exchange，然后根据routes规则，派发到一个或多个queue，
最后消费者获取queue中的消息（push或者是pull方式，rabbitMq貌似是push方式）。
其中，exchange+routes+queue合并称之为broker（代理），也就是消息中间件主体。
对于具体部件的要求，比如针对exchange，有四种类型

image.png

有兴趣的值上官网看类型间的差异。
二、7种不同的工作方式
1、Hello World 完全缺省模式
https://www.rabbitmq.com/tutorials/tutorial-one-java.html

image.png

最简单的方式，缺省的exchenge 不设置routes，最原始消息队列，工作中一般不会这么用，不再展开。
2、Work Queues 工作队列模式
https://www.rabbitmq.com/tutorials/tutorial-two-java.html

image.png

消息产生之后放入一个队列，两个消费者，消息被任意一个消费者消费之后就消失。
官方解释场景，用来处理任务大耗时长的消息，可以理解为一个任务可以派发给任意一个人处理。
3、Publish/Subscribe 发布订阅模式
https://www.rabbitmq.com/tutorials/tutorial-three-python.html

image.png

消息产生后，经过exchanges派发到不同的队列，给不同的客户端消费。
比如日志消息产生后，要分发给打印队列和存储队列，最终完成控制台的打印，和硬盘日志存储两个任务。
4、Routing 路由模式
在3的模式上增加了显示使用路由的方式，如图
https://www.rabbitmq.com/tutorials/tutorial-four-java.html

image.png

继续接3种的场景，日志打印队列需要打印全部日志，而日志存储队列可能只关注error的日志，这时候就可以根据route的规则，配置派发队列的方式。
5、Topic 主题方式
https://www.rabbitmq.com/tutorials/tutorial-five-java.html

image.png

继续4的场景，可以发现区别就是route的规则支持了模糊匹配（当然exchange的type也要改为topic），
*表示1个或多个 #表示0个或多个。
场景如下，比如日志存储队列，希望存储来自宿主机的全部信息+来自应用容器的error信息，就可以用上。
小结：
以上1~5的场景，是层层递进的，1是完全缺省，5是全部配置都上。
狭义的消息队列，用来解耦处理任务，用topic方式就最好了。
6、RPC 远程过程调用
https://www.rabbitmq.com/tutorials/tutorial-six-java.html

image.png

我觉得这个功能应该是比较鸡肋的，大家知道消息队列也可以用来做rpc就好了，实现方式是消息产生之后，要调用消费之后的回调，获取回调的内容。实现远程过程调用的功能。
显示中的rpc很少用队列来做吧。消息队列天生就是用来做异步的，rpc有另外的方案。
7、Publisher Confirms 发布确认？（不会翻译）
https://www.rabbitmq.com/tutorials/tutorial-seven-java.html
这个是消息队列的扩展功能，目的是为了确认消息有没有被正确消费，以topic方式（更低级的更是）为例，
消息被消费者消费了，从队列中移除，而消费者消费消息的结果是不清楚的，可能抛异常了，也可能执行了错误的业务表达了，这时候发布者是完全不知道的。
这个方式就消费者消费完之后 通知生产者，说消费成功了，就这么回事。
如果不成功，也可以告知什么原因，或者期望生产者做什么（是重发，还是咋地）。
应用场景肯定有的，我想到的分布式事务就可以用这个来处理。不过成本也在那，
一般用topic加上日志管理就好了。各位觉得呢