rabbit mq 总结

mq
基于生产消费模式，提供高效可靠异步的消息传递

mq 的好处
低耦合, 各模块通过 mq 间接通信
异步, 消息一发送就返回，无需等待消息消费
缓冲, 把高峰期的请求放入队列，逐个处理
伸缩性, 可以通过增加服务器扩容来支撑更高并发请求和更大的数据存储
扩展性, 增加新功能的时候，容易扩展, 开闭原则, 对修改关闭，对扩展开放

和 rpc 的区别
依赖性, 例如，短信通知不是交易环节的强依赖，如果是rpc调用，短信发送失败有可能导致交易失败，这并不合理，
如果是走 mq，消息通知发送失败也不会影响正常交易
同步性, rpc 是同步的，mq 是异步的
共同点, 都是分布式系统的通信方式

mq 使用场景
1.性能优化, 串性处理并行化, 缩短响应时间
用户注册的时候，用户信息保存数据库后，发个消息给 mq 就返回, 多个消费者, 短信通知，邮件通知 并发处理 

2.应用解耦, 一个步骤失败了，不会妨碍整个业务
短信通知失败了不会妨碍用户正常注册, 系统会重发, 重发多次失败, 系统会监控到，人工会介入处理

3.伸缩性
消息消费速度赶不上消息生产速度, 多部署几个消费者

4.扩展性
对于走了 mq 的业务, 有时候扩展 只要增加一个 queue， 一个消费者就行了
比如创建任务的时候, 原来是发个消息归档, 扩展的时候加一个队列和消费者去建索引

5.流量削峰, 把高并发的请求缓存在队列里，逐个处理

技术选型
rabbitMQ, 中小型项目，万级, 12000，集群不支持负载均衡
rocket mq, 大型项目，十万级，文档少，支持的语言较少
kafka, 大数据实时计算，日志采集，百万级，对ZooKeeeper强依赖

rabbitMQ 的六种模式
1.工作队列模式 Work queues
有多个消费者在监听同一个队列, rabbitmq 会以轮询的方式将消息发给多个消费者, 确保一条消息只会被一个消费者消费

2.发布订阅模式 Publish / subscribe
fanout 交换机把消息广播到绑定它的每一个队列里

3.路由模式 Routing 
direct 交换机把消息转发至路由键完全匹配的队列里

4.主题模式 Topics
topic 交换机把消息转发至路由键模糊匹配的队列里

5.Header 模式
Header 交换机，把消息转发至 Header 匹配上的每一个绑定的队列里，匹配规则根据 header 里的 key/value 键值对，做任一匹配或完全匹配

6.RPC 模式
生产者发的消息，在消息头注明消息 id 和 回复的队列，消费者处理消息后，把处理结果回复到对应的队列里，回复的消息头里需注明回复的消息 id

请求响应模式
------------------
生产者通过消息属性设置
message-id -- 消息的唯一性标识
reply-to -- 回复消息的路由键
------------------
消费者通过消息属性设置
reply-to -- 回复消息的路由键
correlation-Id -- 关联消息的 message-id
通过默认交换机，路由键为默认路由键, 即队列名，发送消息即可
------------------------------------------------------

vhost 需在连接时指定，缺省时使用 /， 缺省用户 guest, 缺省口令
rabbit 创建用户时 必须指定至少一个 vhost

交换机类型
direct, 路由键完全匹配，默认值
fanout, 广播到所有队列, 忽略路由键
topic, 路由键模糊匹配
routingkey 为关键词列表，关键词之间以点号分隔开
// . 将路由键分成几个关键词
// * 匹配一个关键词
// # 匹配零个或多个关键词

默认交换机
由 RabbitMQ 预先声明好的名字为空字符串的直连交换机 direct exchange
每个新建队列（queue）都会自动绑定到默认交换机上，绑定的路由键（routing key）名称与队列名称相同
  
类似 amq.* 的名称的交换机
RabbitMQ 默认创建的交换机，被 RabbitMQ 预留内部使用，不能被应用使用，否则抛出 403 (ACCESS_REFUSED) 错误

队列   direct 交换机
一个队列可以通过多个路由键绑定同一交换机
多个队列用相同的路由键绑定同一交换机，多个队列都能收到相同的消息

临时队列
rabbitMQ 重启就没有了

自动删除队列
当所有消费者断开连接的时候，就自动删除
auto-delete = true, 系统声明的随机队列， 缺省就是随机删除的

消费者独占队列
exclusive = true

自动过期队列
队列超过一定的时间没使用，会被 rabbitMQ 删除， 没使用是指没有 get 操作， 没有消费者连接
x-expires

持久化队列
durable=true, 被保存在磁盘中, rabbitMQ 重启之后还在

发送者确认模式, 确定消息成功到达交换机
配置文件
spring.rabbitmq.publisher-confirms=true
spring.rabbitmq.publisher-confirm-type=correlated

配置类
template.setConfirmCallback(confirmCallback());

消费者接受消息确认, 决定队列里消息删除时机
配置文件
spring.rabbitmq.listener.simple.acknowledge-mode=manual

@Component
@RabbitListener(queues = "sb.info.email")
public class TopicEmailMessageReceiver {
    @RabbitHandler
    public void process(String msg, Channel  channel, Message message) {
    channel.basicAck(message.getMessageProperties().getDeliveryTag(), false);
    }
}

rabbit 会等待消费者显式发回 ack 信号后才从队列中删除消息，否则会一直以已投递未收到消费者确认的状态存在于队列中，直到消费者断开连接，消息重新进入队列
autoAck=true 自动确认
rabbit 会在队列中的消息被消费的时候，立即删除掉
一般采用手动确认，将消息的处理放在 try 里，处理成功就确认应答，catch 异常就拒绝处理

消息到达无人订阅的队列, 会一直在队列中等待，rabbit 默认队列是无限长度的
多个消费者订阅同一队列, 消息以循环的方式发给消费者，每个消息只发送给一个消费者
消息路由到了不存在的队列, rabbit 会忽略，消息丢失

消息的拒绝
消息处理异常，可以拒绝消息，让 rabbit 重新投递
// 第 2 个参数决定是否重新投递
channel.basicReject(envelope.getDeliveryTag(), true); 
// 第 2 个参数决定是否批量
// requeue 第 3 个参数决定是否重新投递
// true,  rabbit 重新投递
// false, rabbit 丢弃
channel.basicNack(envelope.getDeliveryTag(), false, true);

死信的产生
1.消息被拒绝, 并且 requeue=false
2.消息过期, rabbit 默认消息不过期，但可设置队列和消息的过期时间
3.队列达到了最大长度, 当设置了最大队列长度或大小

死信交换机
DLX，Dead-Letter-Exchange
当消息在一个队列中变成死信 (dead message) 之后，它被发送到另一个交换器中，这个交换器就是 DLX，绑定 DLX 的队列就称之为死信队列, 是一个普通的交换机，只是在申明队列的时候，可以配置某个交换机为死信交换机
x-dead-letter-exchange

死信交换机与备用交换机的区别
1.备用交换机用于接收主交换机无法路由的消息，死信交换机用于接收过期或被拒绝的消息
2.备用交换机在申明主交换机时关联，死信交换机在申明队列时关联