1 使用场景
- 系统解耦
- 异步
- 削峰
2 核心概念
- vhost：虚拟主机
- broker:：消息服务进程，包含 exchange 和 queue
- exchange： 交换器。负责根据路由规则转发消息
- queue：消息队列。存储消息的地方，请求“缓冲区”，实现削峰
- producer：消息生产者，发送消息到 交换器
- consumer：消息消费者，从消息队列获取消息并消费
- routingKey：路由标识，producer发送消息时指定，用于匹配queue
- bindingKey：消息队列与交换器绑定时指定的key，用于与消息的routingKey比对
3 exchange交换器类型
1 direct：当消息的routingKey与队列绑定exchange指定的bindingKey 完全一致时，exchange将消息存储到对应的queue
2 fanout：发布订阅，交换器将消息转发到所有与之绑定的queue上，此时消息生产者不能决定消息发往哪里，完全由交换器决定
3 topic：通配符匹配。通配符有 * 、# 两个
*：匹配一个字符，比如 a.* 匹配 a.bingo ，不匹配 a.b.bingo
#： 匹配多个字符，比如 a.# 匹配 a.xx.yy
4 headers：该类型交换器的路由规则使用消息头部携带的键值来匹配，而不使用routingKey
1 交换器与消息队列绑定时，指定键值对信息
2 生产者发送消息时，指定消息的头部信息
headers交换器的匹配模式有 whereAll（全部匹配） 、whereAny（部分匹配） 两种模式
4 工作模式
1 Hello World 模式
点对点模式，一个队列只有一个消费者
2 Work queue 模式
工作队列模式，一个队列由多个消费者并行进行消费。默认情况下rabbitMQ使用 Round-robin 的方式分发消息给消费者。
3 Publish/Subscribe 模式
发布订阅模式，通常使用 fanout 类型的交换器实现，消息转发到与交换器绑定的所有消息队列上。
4 routing 模式
精确匹配路由模式。当routingKey（发送消息时指定的key）与bindingKey（队列绑定交换器时指定的key）完全匹配时，交换器将消息投递到对应的队列。
1 如上图所示，一个队列可多次绑定同一个交换器，并指定不同的 bindingKey
2 多个队列绑定同一个交换器时可指定相同的bindingKey，此时工作模式与发布订阅类似，如下图所示
5 Topic 模式
通配符匹配模式。
6 Rpc 模式
远程调用，请求/响应模式。客户端发出消息后，同步等待直到获取服务端响应的内容后才返回。工作流程大致如下：
- 客户端启动时，创建一个匿名的排他 回调队列，服务端响应的信息将投递到该队列
- 客户端发送rpc请求时，设置
reply_to和correlation_id，reply_to用于指定回调队列，correlation_id用于识别回调队列中的消息对应的是哪一个请求（确定请求源）- 客户端发送请求到
rpc_queue队列- 当消息进入队列时，server消费消息，将响应信息投递到
reply_to队列- 客户端监听
reply_to队列，当有消息到达时，通过correlation_id确定是否是自己请求的结果，如果是则获取信息并返回。
5 如何保证可靠性
1 发送方 publish comfirm 机制。
保证消息从producer到exchange
2 持久化及镜像部署
交换机持久化、队列持久化、消息持久化，保证rabbitMQ服务宕机时，相关的信息不丢失，服务重新上线后能恢复。
镜像部署保证rabbitMQ的高可用。
3 消费方 Ack 机制
确保消息消费成功。
参考博文：
