官网地址：
https://www.rabbitmq.com/documentation.html
简介：
Erlang语言开发，基于AMQP协议(高级消息队列协议)
吞吐量：万级，延迟：微秒级（RocketMQ和Kafka吞吐量十万级，延迟毫秒级）
组件：
虚拟连接Channel(频繁建立TCP连接，消耗性能)
虚拟机vhost(相当于数据库，可在该虚拟机下建队列和交换机)
生产者P
消费者C
队列queue
交换机X
6种工作模式：
1.简单模式
只使用到queues
2.工作队列模式 work queues
只使用到queues，多个消费者轮询，可根据消费者的性能设置消费一条后再获取新的消息。
3.发布订阅模式
1）.fanout广播：将消息交给所有绑定交换机的队列
2）.direct定向(路由)：将消息交给符合指定routing key的队列
3）.topic主题(通配符)：把消息交给符合routing pattern（路由模式）的队列
Exchange(交换机)：只负责转发消息，不具备存储消息的能力，因此如果没有任何队列和交换机绑定，或者没有符合路由规则的队列，那么消息会丢失。
4.RPC模式：不常使用
消息确认机制：
RabbitMQ提供监听器来接收消息的投递状态，消息确认涉及两种状态：confirm和return。
confirm：
代表生产者将消息送到broker时产生的状态，会出现两种情况：
1.ack:代表broker已经将消息接收
2.nack:代表broker拒收消息，原因有很多：队列已满，限流，IO异常......
return：
代表消息被broker正常接收(ack)后，但broker没有对应的队列进行投递时产生的状态，消息被退还给生产者。
注意：上面两种状态只代表生产者跟broker之间消息投递的情况，与消费者是否接收/确认消息无关。
参数配置：
publisher-confirms=true
publisher-returns=true、
基础架构：
spring boot整合rabbitmq:
消费者监听器：实现ChannelAwareMessageListener
高级特性：
1.消息的可靠性投递
消息投递路径：producer-->rabbitmq broker-->exchange-->queue-->comsumer
a. 消息从producer到exchange则会返回一个confirmCallback
b.消息从exchange到queue投递失败则会返回一个returnCallback
利用这两个callback控制消息的可靠性投递。
2.consumer ack
ack指acknowledge 确认。表示消费者收到消息后的确认方式
a.自动确认：acknowledge="none"
消息一旦被consumger收到，自动确认收到，将message从rabbitmq的消息缓存中移除；实际业务中，处理消息可能出现异常，那么该消息就会丢失。
b.手动确认；acknowledge="manual"
在业务处理成功后，调用channel.basicAck(),手动签收；如果出现异常，调用channel.basicNack()，让其自动重新发送消息(requeue参数控制，true时重新发送，false时丢弃消息)，对于重发几次仍然异常的消息，可以放到redis/日志文件/数据库中后续处理。
c.根据异常情况确认：acknowledge="auto"
消息可靠性总结：
1.持久化：exchange持久化，queue持久化，message持久化
2.生产方确认confirm
3.消费方确认ack
4.broker高可用
3.消费端限流
要求：消息确认模式选择手动确认：acknowledge="manual"
配置：监听器的prefetch属性设置消费端一次拉取多少消息。
4.TTL time to live 存活时间/过期时间 单位毫秒 当消息到达存活时间后，还没有被消费，会被自动清除
rabbitmq可以对消息设置过期时间：expiration，也可以对整个队列(对该队列的所有消息有效)设置过期时间:x-message-ttl;两者都设置，以时间段的为准。
5.死信队列
rabbtimq中也称死信交换机 DLX
当消息成为dead message后，可以重新被发送到另一个交换机，这个交换机就是DLX。
配置：
1.声明正常的交换机和队列并绑定
2.声明死信交换机和队列并绑定
3.正常队列绑定死信交换机
a.x-dead-letter-exchange:死信交换机名称
b.x-dead-letter-routing-key:死信交换机的routingkey
消息成为死信的三种情况:
1.队列消息长度到达限制
2.消费者拒接消费信息，并且不从回队列
3.原队列存在消息过期限制，消息到达超时时间未被消费
6.延迟队列 TTL+死信队列
应用：
下单30分钟内未支付，取消订单，回滚库存
新用户注册7天后，发送短信问候
......
消息积压：
消费者宕机积压；消费者消费能力不足积压；发送者发送量太大
解决方案：上线更多的消费者；上线专门的队列消费服务；批量取出消息，记录数据库，再慢慢处理。
消息幂等性保障：
一次和多次请求某一资源，对资源本身具有相同的结果。
在 MQ中指，消费多条相同的消息，得到与消费该消息一次相同的结果。
--乐观锁机制：
集群搭建:参考：http://rabbitmq.com/clustering.html
负载均衡-HAProxy
HAProxy提供高可用性，负载均衡以及基于TCP和HTTP应用的代理，支持虚拟主机，是免费，快速并且可靠的一种解决方案。
HAProxy实现了一种事件驱动，单一进程模型，此模型支持非常大的并发连接数。