rabbitMQ从零开始到入门

最近学习了下rabbitMQ记录一下
什么叫中间件？
中间件：非底层操作系统软件、非业务应用软件，不是直接给最终用户使用的，不能直接给客户带来价值的软件，统称中间件。常见的有如下几种：服务中间件、集成中间件、数据中间件、消息中间件、安全中间件。
其中用Java实现的中间件，统称Java中间件。

MQ 是什么？队列是什么，MQ 我们可以理解为消息队列，队列我们可以理解为管道。以管道的方式做消息传递。
RabbitMQ 、activeM 、ZeroMQ 三者中，综合来看，RabbitMQ是首选。
RabbitMq / Kafka 最好，ActiveMq 次之，ZeroMq 最差。当然ZeroMq 也可以做到，不过自己必须手动写代码实现，代码量不小。尤其是可靠性中的：持久性、投递确认、发布者证实和高可用性。
4.高并发
毋庸置疑，RabbitMQ 最高，原因是它的实现语言是天生具备高并发高可用的erlang 语言。
5.比较关注的比较， RabbitMQ 和 Kafka
RabbitMq 比Kafka 成熟，在可用性上，稳定性上，可靠性上， RabbitMq 胜于 Kafka （理论上）。
另外，Kafka 的定位主要在日志等方面， 因为Kafka 设计的初衷就是处理日志的，可以看做是一个日志（消息）系统一个重要组件，针对性很强，所以 如果业务方面还是建议选择 RabbitMq 。
还有就是，Kafka 的性能（吞吐量、TPS ）比RabbitMq 要高出来很多。
消息中间件：
一.RabbitMQ
更成熟。
二.kafka
新设计理念，就是快。
等。。。
RPC
一.dubbo
阿里开源rpc,用的超多，比HTTP接口快啊，各有好处。

RabbitMQ 学习
一、RabbitMQ介绍
1、RabbitMQ简介
RabbitMQ是一个消息代理：它接受和转发消息。你可以把它想象成一个邮局：当你把你想要发布的邮件放在邮箱中时，你可以确定邮差先生最终将邮件发送给你的收件人。在这个比喻中，RabbitMQ是邮政信箱，邮局和邮递员。
RabbitMQ和邮局的主要区别在于它不处理纸张，而是接受，存储和转发二进制数据块 - 消息。引自（https://www.rabbitmq.com/tutorials/tutorial-one-java.html）官网介绍。
尽管消息流经RabbitMQ，但它们只能存储在队列中。一个队列只受主机内存和磁盘限制的约束，它本质上是一个很大的消息缓冲区。许多生产者可以发送进入一个队列的消息，并且许多消费者可以尝试从一个队列接收数据。实质上是生产者——消费者关系。

2、什么叫消息队列
消息（Message）是指在应用间传送的数据。消息可以非常简单，比如只包含文本字符串，也可以更复杂，可能包含嵌入对象。
消息队列（Message Queue）是一种应用间的通信方式，消息发送后可以立即返回，由消息系统来确保消息的可靠传递。消息发布者只管把消息发布到 MQ 中而不用管谁来取，消息使用者只管从 MQ 中取消息而不管是谁发布的。这样发布者和使用者都不用知道对方的存在。
（注：该段引用来源：https://www.jianshu.com/p/79ca08116d57）

3、为何用消息队列
从上面的描述中可以看出消息队列是一种应用间的异步协作机制，那什么时候需要使用 MQ 呢？
以常见的订单系统为例，用户点击【下单】按钮之后的业务逻辑可能包括：扣减库存、生成相应单据、发红包、发短信通知。在业务发展初期这些逻辑可能放在一起同步执行，随着业务的发展订单量增长，需要提升系统服务的性能，这时可以将一些不需要立即生效的操作拆分出来异步执行，比如发放红包、发短信通知等。这种场景下就可以用 MQ ，在下单的主流程（比如扣减库存、生成相应单据）完成之后发送一条消息到 MQ 让主流程快速完结，而由另外的单独线程拉取MQ的消息（或者由 MQ 推送消息），当发现 MQ 中有发红包或发短信之类的消息时，执行相应的业务逻辑。
以上是用于业务解耦的情况，其它常见场景包括最终一致性、广播、错峰流控等等。

4、RabbitMQ 特点
RabbitMQ 是一个由 Erlang 语言开发的 AMQP 的开源实现。

AMQP ：Advanced Message Queue，高级消息队列协议。它是应用层协议的一个开放标准，为面向消息的中间件设计，基于此协议的客户端与消息中间件可传递消息，并不受产品、开发语言等条件的限制。

RabbitMQ 最初起源于金融系统，用于在分布式系统中存储转发消息，在易用性、扩展性、高可用性等方面表现不俗。具体特点包括：

（1）可靠性（Reliability）
RabbitMQ 使用一些机制来保证可靠性，如持久化、传输确认、发布确认。

（2）灵活的路由（Flexible Routing）
在消息进入队列之前，通过 Exchange 来路由消息的。对于典型的路由功能，RabbitMQ 已经提供了一些内置的 Exchange 来实现。针对更复杂的路由功能，可以将多个 Exchange 绑定在一起，也通过插件机制实现自己的 Exchange 。

（3）消息集群（Clustering）
多个 RabbitMQ 服务器可以组成一个集群，形成一个逻辑 Broker 。

（4）高可用（Highly Available Queues）
队列可以在集群中的机器上进行镜像，使得在部分节点出问题的情况下队列仍然可用。

（5）多种协议（Multi-protocol）
RabbitMQ 支持多种消息队列协议，比如 STOMP、MQTT 等等。

（6）多语言客户端（Many Clients）
RabbitMQ 几乎支持所有常用语言，比如 Java、.NET、Ruby 等等。

（7）管理界面（Management UI）
RabbitMQ 提供了一个易用的用户界面，使得用户可以监控和管理消息 Broker 的许多方面。

（8）跟踪机制（Tracing）
如果消息异常，RabbitMQ 提供了消息跟踪机制，使用者可以找出发生了什么。

（9）插件机制（Plugin System）
RabbitMQ 提供了许多插件，来从多方面进行扩展，也可以编写自己的插件。

（注：该段引用来源：https://www.jianshu.com/p/79ca08116d57）

（1）Message
消息，消息是不具名的，它由消息头和消息体组成。消息体是不透明的，而消息头则由一系列的可选属性组成，这些属性包括routing-key（路由键）、priority（相对于其他消息的优先权）、delivery-mode（指出该消息可能需要持久性存储）等。
（2）Publisher
消息的生产者，也是一个向交换器发布消息的客户端应用程序。
（3）Exchange
交换器，用来接收生产者发送的消息并将这些消息路由给服务器中的队列。
（4）Binding
绑定，用于消息队列和交换器之间的关联。一个绑定就是基于路由键将交换器和消息队列连接起来的路由规则，所以可以将交换器理解成一个由绑定构成的路由表。
（5）Queue
消息队列，用来保存消息直到发送给消费者。它是消息的容器，也是消息的终点。一个消息可投入一个或多个队列。消息一直在队列里面，等待消费者连接到这个队列将其取走。
（6）Connection
网络连接，比如一个TCP连接。
（7）Channel
信道，多路复用连接中的一条独立的双向数据流通道。信道是建立在真实的TCP连接内地虚拟连接，AMQP 命令都是通过信道发出去的，不管是发布消息、订阅队列还是接收消息，这些动作都是通过信道完成。因为对于操作系统来说建立和销毁 TCP 都是非常昂贵的开销，所以引入了信道的概念，以复用一条 TCP 连接。
（8）Consumer
消息的消费者，表示一个从消息队列中取得消息的客户端应用程序。
（9）Virtual Host
虚拟主机，表示一批交换器、消息队列和相关对象。虚拟主机是共享相同的身份认证和加密环境的独立服务器域。每个 vhost 本质上就是一个 mini 版的 RabbitMQ 服务器，拥有自己的队列、交换器、绑定和权限机制。vhost 是 AMQP 概念的基础，必须在连接时指定，RabbitMQ 默认的 vhost 是 / 。
（10）Broker
表示消息队列服务器实体。

方法介绍
1、
// 声明一个队列 -// queue 队列名称
// durable 为true时server重启队列不会消失 (是否持久化)

是否持久化, 队列的声明默认是存放到内存中的，如果rabbitmq重启会丢失，如果想重启之后还存在就要使队列持久化，保存到Erlang自带的Mnesia数据库中，当rabbitmq重启之后会读取该数据库
// exclusive 队列是否是独占的，如果为true只能被一个connection使用，其他连接建立时会抛出异常，一般等于true的话用于一个队列只能有一个消费者来消费的场景
是否排外的，有两个作用，一：当连接关闭时connection.close()该队列是否会自动删除；二：该队列是否是私有的private，如果不是排外的，可以使用两个消费者都访问同一个队列，没有任何问题，如果是排外的，会对当前队列加锁，其他通道channel是不能访问的，如果强制访问会报异常
// autoDelete 为true时当没有任何消费者使用时，自动删除该队列
是否自动删除，当最后一个消费者断开连接之后队列是否自动被删除，可以通过RabbitMQ Management，查看某个队列的消费者数量，当consumers = 0时队列就会自动删除
channel.queueDeclare(QUEUE_NAME, false, false, false, null);
2、
/*
* 向server发布一条消息
* 参数1：exchange名字，若为空则使用默认的exchange
* 参数2：routing key
* 参数3：其他的属性
* 参数4：消息体
* RabbitMQ默认有一个exchange，叫default exchange，它用一个空字符串表示，它是direct exchange类型，
* 任何发往这个exchange的消息都会被路由到routing key的名字对应的队列上，如果没有对应的队列，则消息会被丢弃
*/
channel.basicPublish("", QUEUE_NAME, null, message.getBytes(“UTF-8”));
3、
// 同一时刻服务器只会发一条消息给消费者(能者多劳模式)
channel.basicQos(1);
4、
/*消息消费完成确认
* autoAck 是否自动确认 true自动确认 false手动确认
* 模式1：自动确认 只要消息从队列中获取，无论消费者获取到消息后是否成功消息，都认为是消息已经成功消费。
* 模式2：手动确认
* 消费者从队列中获取消息后，服务器会将该消息标记为不可用状态，等待消费者的反馈，如果消费者一直没有反馈，那么 该消息 将一直处于不可用状态。
* 如果选用自动确认,在消费者拿走消息执行过程中出现宕机时,消息可能就会丢失！！
*/
channel.basicConsume(TASK_QUEUE_NAME, false, consumer);
当手动确认时，一定要在消息处理完成后，确认提交，加上如下代码：
　 // 消息处理完成，手动确认提交
// deliveryTag 该消息的index
// multiple：是否批量 true:将一次性ack所有小于deliveryTag的消息。
channel.basicAck(envelope.getDeliveryTag(), false);

/*
* 使用fanout类型创建的交换器
* exchange：交换机名称
* type：交换机类型(direct/topic/fanout)
*/
channel.exchangeDeclare(EXCHANGE_NAME, ConfigKey.EX_FANOUT,true);
为true交换机持久化

/*
* 获取到一个临时队列名称。
* channel.queueDeclare()：创建一个非持久化、独立、自动删除的队列名称
* 此队列是临时的，随机的，一旦我们断开消费者，队列会立即被删除
* 随机队列名，如amq.gen-jzty20brgko-hjmujj0wlg
/
String queueName = channel.queueDeclare().getQueue();
/
* 将队列跟交换器进行绑定
* queue：队列名称
* exchange：交换机名称
* routingKey：队列跟交换机绑定的键值
*/
channel.queueBind(queueName, EXCHANGE_NAME, “black”);

2、工作队列（work queue）

使用工作队列实现任务分发的功能，一个队列的优点就是很容易处理并行化的工作能力，但是如果我们积累了大量的工作了，我们就需要更多的工作者来处理，这里就要采用分布机制了。

2.1、交换机的直连接类型direct：
适用场景：有优先级的任务，根据任务的优先级把消息发送到对应的队列，这样可以指派更多的资源去处理高优先级的队列。
2.2、临时队列（Temporary queues）
Java中我们可以使用queueDeclare()方法，不传递任何参数，来创建一个非持久的、唯一的、自动删除的队列且队列名称由服务器随机产生。
2.3、轮询分发（Round-robin）
在默认情况下，RabbitMQ将逐个发送消息到在序列中的下一个消费者(而不考虑每个任务的时长等等，且是提前一次性分配，并非一个一个的分配)。平均每个消费者获得相同数量的消息。这种方式分发消息机制称为Round-Robin（轮询）。
当消息进入队列，RabbitMQ就会分派消息。它不看消费者的应答的数目，也不关心消费者处理消息的能力，只是盲目的暴力的将第n条消息发给第n个消费者。
2.4、公平转发（Fair dispatch）
当工作队列中有两个消费者中，可以看到消费者1收到的消息都是偶数条，消费者1都是奇数条，假如偶数条的消息处理比较耗时，奇数条的消息处理很快耗时短，当有多条消息在队列中，队列一下子就把所有奇数条消息推送给消费者1，把所有偶数条消息推送给消费者2，由于消费者1处理的消息不叫耗时，消费者2处理比较快，很可能出现当消费者1才处理几条的时，消费者2就已经完全处理了，这样消费者2就处理空闲状态，而消费者1却忙的跟狗似的。为了解决这种现象，让干的快的干完了帮助干的慢的分担点任务，RabbitMQ采用限制消费者一次从队列中获取消息的条数，而不是一下子把满足条件的消息都推送个某个消费者，通过使用channel.basicQos(1)告诉消费者一次只能从队列中预先获取一条(预提取数量prefetchCount)，处理完了再获取另一条，这样其他消息仍然在队列中，还没有被分发出去，这样就会造成处理消息慢的继续处理当前消息，处理消息的快的由于一次只能从队列中获取一条，处理完继续从队列中获取，这样就会出现能者多劳，大家谁都不会闲着。使用公平转发这种方式支持动态添加消费者，比如队列中的消息很多，两个消费者处理不过来，需要再增加消费者来处理，由于消息还在队列中，还没有被分发出去，这样再增加消费者，消费者就能马上从队列中获取消息，立即投入进来工作。
2.5、消息持久化
默认队列和消息都是放在内存中的，当RabbitMQ退出或者崩溃，将会丢失队列和消息。为了保证即使RabbitMQ崩溃也不会丢失消息，我们必须把“队列”和“消息”设为持久化，当队列和消息持久化以后即使RabbitMQ崩溃，消息还存在数据库中，当RabbitMQ再次启动的时候，队列和消息仍然还在。消息持久化需要将交换机持久化、队列持久化、消息持久化，才能最终达到持久化的目的
// 队列持久化
boolean durable = true;
channel.queueDeclare(“hello”, durable, false, false, null);
// 消息持久化 方式一
channel.basicPublish("", “key”, MessageProperties.PERSISTENT_TEXT_PLAIN, message.getBytes(“UTF-8”));
// 消息持久化 方式二
AMQP.BasicProperties.Builder properties = new AMQP.BasicProperties().builder();
properties.deliveryMode(2); // 设置消息是否持久化，1： 非持久化 2：持久化
channel.basicPublish("", “key”, properties.build(), message.getBytes(“UTF-8”));

3、扇形交换器fanout
扇形交换机是最基本的交换机类型，它所能做的事情非常简单———广播消息。扇形交换机会把能接收到的消息全部发送给绑定在自己身上的队列。因为广播不需要“思考”，所以扇形交换机处理消息的速度也是所有的交换机类型里面最快的。uiltinExchangeType.FANOUT
每个消费者收到同样数量的消息，因为队列里面的消息
// 生产者不需要队列声明，也不需要声明交换机，只需要指定交换机的名称即可，队列和交换机的声明可以在消费者中声明

4、路由选择routing，多个队列绑定到同一个交换器

5、主题交换机Topics类型
主题类型topic，直连接类型direct必须是生产者发布消息指定的routingKey和消费者在队列绑定时指定的routingKey完全相等时才能匹配到队列上，与direct不同,topic可以进行模糊匹配，可以使用星号*和井号#这两个通配符来进行模糊匹配，其中星号可以代替一个单词；主题类型的转发器的消息不能随意的设置选择键（routing_key），必须是由点隔开的一系列的标识符组成。标识符可以是任何东西，但是一般都与消息的某些特性相关。一些合法的选择键的例子：“quick.orange.rabbit”,你可以定义任何数量的标识符，上限为255个字节。 #井号可以替代零个或更多的单词，只要能模糊匹配上就能将消息映射到队列中。当一个队列的绑定键为#的时候，这个队列将会无视消息的路由键，接收所有的消息

6、远程过程调用RPC:

远程过程调用(RPC): 客户端发送一个请求到远程服务器上，远程服务器接收请求并处理结果，将结果响应给客户端，这个过程被称为远程过程调用.
RPC的过程描述：
客户端首先将请求消息发送到请求队列，在发送请求时需要指定replyTo和correlationId两个值；
服务端需要预先订阅请求队列(rpc_queue),以便服务器端能随时接受到请求消息，当服务端接收到请求消息时对请求进行处理，将处理结果发送到响应队列(随机队列)中
客户端还要预先订阅响应队列(随机队列)，以便当服务器发送响应消息到响应队列中，客户端能及时收到响应结果，服务器在将响应发送到响应队列中还要指定correlationId值(类似于唯一标记当前的请求)，这样当客户端从响应队列中接收到消息时就可以通过correlationId的值是否和发送请求的关联id值是否相同，如果相同就证明这个响应结果就是这个请求对应的响应结果。注意这个预先订阅响应队列的步骤需要在客户端中完成，最好在客户端发送请求消息前就完成。

7、首部交换机Headers

直连接和首部类型的比较
绑定规则不同：直连接是一个简单的String；而首部是键值对Entry，而且键值对的value可以是任意类型Object
绑定个数不同：直连接一次只能绑定一个字符串，如果想绑定多个字符串就需要绑定多次或者循环调用queueBind()方法来绑定多次；而首部类型直接可以往Map中添加多个实体Entry即可
映射规则不同：直连接只需要比较路由键是否相等即可，而首部类型除了比较value还要比较key，因为首部类型是Entry类型，需要同时比较key和value，而且首部类型还可以通过x-match来控制匹配的条件，all：需要匹配所有Entry，相当于SQL中的 and操作，any：只需要匹配上一个Entry即可，相当于SQL中的or操作
直连接适用于计较简单的路由，而首部类型相比直连接匹配规则更强大