简述RabbitMQ的架构设计
-
Broker：rabbitmq的服务节点
-
Queue：队列，是RabbitMQ的内部对象，用于存储消息。RabbitMQ中消息只能存储在队列中。生产者投递消息到队列，消费者从队列中获取消息并消费。多个消费者可以订阅同一个队列，这时队列中的 消息会被平均分摊(轮询)给多个消费者进行消费，而不是每个消费者都收到所有的消息进行消费。(注意：RabbitMQ不支持队列层面的广播消费，如果需要广播消费，可以采用一个交换器通过路由Key绑定多个队列，由多个消费者来订阅这些队列的方式。
-
Exchange：交换机。生产者将消息发送到Exchange，由交换器将消息路由到一个或多个队列中。如果路由不到，或返回给生产者，或直接丢弃，或做其它处理。
-
RoutingKey：路由Key。生产者将消息发送给交换器的时候，一般会指定一个RoutingKey，用来指定这个消息的路由规则。这个路由Key需要与交换器类型和绑定键(BindingKey)联合使用才能最终生效。 在交换器类型和绑定键固定的情况下，生产者可以在发送消息给交换器时通过指定RoutingKey来决定消息流向哪里。
-
Binding：通过绑定将交换器和队列关联起来，在绑定的时候一般会指定一个绑定键，这样RabbitMQ 就可以指定如何正确的路由到队列了。
-
交换器和队列实际上是多对多关系。就像关系数据库中的两张表。他们通过BindingKey做关联(多对多关系表)。在投递消息时，可以通过Exchange和RoutingKey(对应BindingKey)就可以找到相对应的队列。
-
信道：信道是建立在Connection 之上的虚拟连接。当应用程序与Rabbit Broker建立TCP连接的时候， 客户端紧接着可以创建一个AMQP 信道(Channel) ，每个信道都会被指派一个唯一的ID。RabbitMQ 处理的每条AMQP 指令都是通过信道完成的。信道就像电缆里的光纤束。一条电缆内含有许多光纤束，允许所有的连接通过多条光线束进行传输和接收。
RabbitMQ如何确保消息发送？消息接收？
发送方确认机制：
信道需要设置为 confirm 模式，则所有在信道上发布的消息都会分配一个唯一 ID。
一旦消息被投递到queue（可持久化的消息需要写入磁盘），信道会发送一个确认给生产者（包含消息唯一 ID）。
如果 RabbitMQ 发生内部错误从而导致消息丢失，会发送一条 nack（未确认）消息给生产者。
所有被发送的消息都将被 confirm（即 ack） 或者被nack一次。但是没有对消息被 confirm 的快慢做 任何保证，并且同一条消息不会既被confirm又被nack
发送方确认模式是异步的，生产者应用程序在等待确认的同时，可以继续发送消息。当确认消息到达生产者， 生产者的回调方法会被触发。
ConfirmCallback接口：只确认是否正确到达Exchange中，成功到达则回调
ReturnCallback接口：消息失败返回时回调
接收方确认机制：
消费者在声明队列时，可以指定noAck参数，当noAck=false时，RabbitMQ会等待消费者显式发回ack信号 后才从内存(或者磁盘，持久化消息)中移去消息。否则，消息被消费后会被立即删除。
消费者接收每一条消息后都必须进行确认（消息接收和消息确认是两个不同操作）。只有消费者确认了消息， RabbitMQ 才能安全地把消息从队列中删除。
RabbitMQ不会为未ack的消息设置超时时间，它判断此消息是否需要重新投递给消费者的唯一依据是消费该消息的消费者连接是否已经断开。这么设计的原因是RabbitMQ允许消费者消费一条消息的时间可以很长。保证数据的最终一致性；
如果消费者返回ack之前断开了链接，RabbitMQ 会重新分发给下一个订阅的消费者. (可能存在消息重复消费的隐患，需要去重)
RabbitMQ事务消息
通过对信道的设置实现：
- channel.txSelect()；通知服务器开启事务模式；服务端会返回Tx.Select-Ok
- channel.basicPublish；发送消息，可以是多条，可以是消费消息提交ack
- channel.txCommit()提交事务；
- channel.txRollback()回滚事务；
消费者使用事务：
- autoAck=false，手动提交ack，以事务提交或回滚为准；
- autoAck=true，不支持事务的，也就是说你即使在收到消息之后在回滚事务也是于事无补的，队列已经把消息移除了
如果其中任意一个环节出现问题，就会抛出IoException异常，用户可以拦截异常进行事务回滚，或决 定要不要重复消息
事务消息会降低rabbitmq的性能
RabbitMQ死信队列，延时队列
如果：
- 消息被消费方否定确认，使用 channel.basicNack 或 channel.basicReject ，并且此时 requeue 属性被设置为 false 。
- 消息在队列的存活时间超过设置的TTL时间。
- 消息队列的消息数量已经超过最大队列长度。
那么该消息将成为“死信”。“死信”消息会被RabbitMQ进行特殊处理，如果配置了死信队列信息，那么该消息将会被丢进死信队列中，如果没有配置，则该消息将会被丢弃
为每个需要使用死信的业务队列配置一个死信交换机，这里同一个项目的死信交换机可以共用一个，然后为每个业务队列分配一个单独的路由key，死信队列只不过是绑定在死信交换机上的队列，死信交换机也不是什么特殊的交换机，只不过是用来接受死信的交换机，所以可以为任何类型【Direct、 Fanout、Topic】
TTL：一条消息或者该队列中的所有消息的最大存活时间
如果一条消息设置了TTL属性或者进入了设置TTL属性的队列，那么这条消息如果在TTL设置的时间内没有被消费，则会成为“死信”。如果同时配置了队列的TTL和消息的TTL，那么较小的那个值将会被使用。
只需要消费者一直消费死信队列里的消息
RabbitMQ镜像队列机制
镜像queue有master节点和slave节点。master和slave是针对一个queue而言的，而不是一个node作 为所有queue的master，其它node作为slave。一个queue第一次创建的node为它的master节点，其 它node为slave节点。
无论客户端的请求打到master还是slave最终数据都是从master节点获取。当请求打到master节点时， master节点直接将消息返回给client，同时master节点会通过GM（Guaranteed Multicast）协议将 queue的最新状态广播到slave节点。GM保证了广播消息的原子性，即要么都更新要么都不更新。
当请求打到slave节点时，slave节点需要将请求先重定向到master节点，master节点将将消息返回给 client，同时master节点会通过GM协议将queue的最新状态广播到slave节点。
如果有新节点加入，RabbitMQ不会同步之前的历史数据，新节点只会复制该节点加入到集群之后新增 的消息。