通过Docker 安装

docker pull rabbitmq:management

docker run -d --name rabbit -v /mydata/rabbitmq:/var/lib/rabbitmq -e RABBITMQ_DEFAULT_USER=admin -e RABBITMQ_DEFAULT_PASS=admin -p 15672:15672 -p 5672:5672 -p 25672:25672 -p 61313:61313 -p 1883:1883 rabbitmq:management

docker update rabbit --restart=always

虚拟主机可以类比MySQL的库

工作模式

（1）直连模式

• 一个生产者生成消息，一个消费者消费消息，中间的消息队列进行消息的缓存和传递
• 适用于点对点的场景，比如用户登录成功后，增加积分。

（2）工作队列 Work Queue

当消息处理比较耗时的时候，可能生产消息的速度会远远大于消费的速度。长此以往，形成消息堆积。

此时，可以使多个消费者绑定到队列中，共同消费队列中的消息。队列中的消息一旦消费，就会消失，避免消息的重复消费。

• 默认是轮询，消费者1一个消息，消费者2一个消息，消费者1再一个消息
• 为了避免因消费者突然宕机而丢失消息，需关闭自动确认机制。在真正消费完时，再手动确认。

（3）广播模式 fanout

• 基本流程

  • 每个消费者都有自己的临时队列queue
  • 每个队列必须绑定到交换机Exchange
  • 生产者发送消息时，只能先发送到交换机，由交换机来决定发送到哪个队列中。
  • 队列的消费者都能拿到消息 —> 一条消息被多个消费者消费

  比如订单系统和库存系统均为消费者，当用户已提交订单的消息通过广播传送给每个消费者时，每个消费者做出自己的响应。

（4）路由模型 Routing

fanout模型下，生产者发布消息时，交换机将消息转发给所有消费者；而路由模型下，交换机选择性地将消息转发给消费者。

类型	示意图	解释
Routing 下的direct		(1)临时队列与交换机通过RoutingKey进行绑定； (2)生产者向交换机发送消息时，也必须指定RoutingKey (3)只有两个key一致时，交换机才会将消息转发给相应的消费者
Routing下的topic		相比于direct中固定的key，topic支持表达式类型的key，实现了动态路由

SpringBoot下，关闭自动确认。