可靠性投递
服务端向生产者ACK
消息发送到exchange失败ack=false，成功ack=true，需配置pulishConfirs=true
路由<br>
exchange路由到queue失败则返回消息，需配置mandatory=true<br>
队列存储<br>
exchange、queue及消息在内存中存储，重要性高的消息需要配置exchange、queue的持久化即durable=true
消费者向服务端ACK
自动ACK机制在消费者受到消息后，不管后续是否处理正确，都会立即ACK。需要配置手动ACK，在正确处理完成后手动调用ACK方法<br>
回调<br>
消费者处理完成后，通过接口或另一个queue返回成功消息，让生产者知道消息已正确处理，修改状态。（视业务而定，这么做会增加耦合性）
重发
生产者发送的某条消息，在指定的时间内没有收到消费者的回调，则将这条消息重发（可按照需要配置重发次数）
补偿
区别于重发的发生，在消费端使用补偿队列（一个延时队列）对消息的消费做补偿，使偶然状态下失败的消息可以重新消费
幂等
由于重发和补偿的机制，可能造成消息的重复消费，使用唯一标识做判断，如果已消费则抛弃
高可用集群
普通集群
只有一个节点会存放消息，其他的节点只是对交换机、队列等组件做了复制
镜像集群
所有的节点都是一样的，节点与节点之间做消息同步（所有节点同步消息必然会导致吞吐量下降）
负载均衡
对集群的中的每个节点做负载均衡，可以通过HAProxy+KeepAlive来做<br>
MQ的作用<br>
异步
例如注册账户成功后立即返回成功，后续如果需要发送短信或邮件通知到用户，可以将通知这一步扔到消息队列中异步执行
解耦
对于生产消息的生产者而言，只要往队列中发送消息就可以了，不用关心消费者是怎么消费消息的，也不用关心是哪个消费者消费消息
削峰
高峰期访问的数据放入到队列中，由消费者按照节奏消费，起一个削峰填谷的作用
MQ带来的问题
系统可用性降低
不仅仅是MQ，项目中每多一个中间件，都会增加整个系统的宕机风险（中间件挂了，系统中的某些功能可能就不能用了）
系统复杂性增加<br>
本来一个接口完事儿，加入队列又要维护生产者，又要维护消费者，还得处理消息丢失、重复消费等问题
学习、运维成本增加
团队中需要学习，运维也需要多维护这个中间件
RabbitMQ的理论模型<br>
核心组件
VHost
虚拟主机，可以创建多个虚拟主机，再给不同的用户分配不同的主机权限
Channel
信道，在每个建立好的TCP长连接中创建信道做消息的传入传出
Exchange
交换机，生产者将消息通过channel发送到交换机，交换机再路由到各个队列中
RoutingKey
路由键，与队列绑定，交换机通过消息中的路由键路由到与路由键绑定的队列中
交换机路由方式
主题Topic<br>
除了完全匹配以外，还可以通过两种通配符来转发
*：代表一个单词
#：啥都可以
广播Fanout<br>
会对关联的所有队列都发送消息
消费模型
pull：消费者主动从队列中拉取消息
push：消费者被动获取队列推送给它的消息（Spring amqp的主要方式，可以通过basicQos设置在ack前最多接收多少条推送）
