MQ安装与使用

安装

docker run -d --name rabbitmq -p 5671:5671 -p 5672:5672 -p 4369:4369 -p 25672:25672 -p 125672:125672 -p 125671:125671 rabbitmq:management

端口解释：

4369, 25672 (Erlang发现&集群端口)

5672，5671 （AMQP端口）

15672 （web管理后台端口）

61613 61614 （STOMP协议端口）

1883 8883（MQTT端口协议）

 

Exchange类型

Exchange分发消息时根据类型有不同的分发策略，目前共有4种:direct,fanout,topic headers.headers匹配AMQP消息的header而不是路由键，headers交换器和direct交换器完全一致，但是性能差很多，目前几乎用不到

direct Exchange （根据绑定关系精确匹配信息 ）

消息中的路由键如果是和Binding中的binding key完全一致，交换器就会将消息发到对应的队列中。路由键与队列名完全匹配，如果一个队列绑定到交换机要求路由键为"dog",那么只转发routingkey标记为dog的消息，不会转发dog.puppy等其他消息，它是完全匹配的单播模式

Topic Exchange 

topic交换器通过模式匹配分配消息的路由键属性，将路由键和某个模式进行匹配，此时队列需要绑定到一个模式上，它将路由键和绑定键的字符串切分成单词，这些单词之间用点分开，它同样也会识别两个通配符：# *  

#： 匹配0个或多个单词

*： 匹配一个单词

 

消息确认机制-可靠抵达

• 为了保证消息不丢失，可靠抵达，可以使用事务消息，性能下降250倍，为此引入确认机制
• publisher confirmCallback 确认模式
• publisher returnCallback 未投递到queue退回模式
• consumer ack机制

可靠抵达-confirmCallback

spring.rabbitmq.publisher-confirms=true

• 在创建connectuinFactory的时候设置PublisherConfirms(true)选项，开启confirmCallback
• CorrelationData:用来表示当前消息唯一性
• 消息只要被Broker接收到就会执行confirmCallBack,如果是cluster模式，需要所有的broker接收到确认才会调用confirmCallback
• 被broker接收到的消息只能表示消息message已经到达服务器，并不能保证消息一定会被投递到目标queue,所以需要接下来的returnCallback

可靠抵达-Ack消息确认机制

消费者获取到消息，成功处理，可以回复Ack给Broker

• basic.ack用于肯定确认，broker将会移除此消息
• basic.nack用于否认消息，可以指定broker是否丢弃此消息，可以批量
• basic.reject用于否认消息，同上，不能批量处理

默认，消息被消费者接收到，就会从broker的队列queue中移除

queue队列中无消费者，消息依然会被存储，直到消息被消费者消费

消费者收到消息，默认会进行ack,但是如果无法确认消息是否被处理完成，或者成功处理，可以进行手动的ack回复