消息队列学习
exchange：一个应用对应一个exchange
Routing key：exchange根据routing key的配置，决定将消息路由到哪个队列
为了确保消息不会丢失，RabbitMQ支持消息确认机制。客户端在接受到消息并处理完后，可以发送一个ack消息给RabbitMQ，告诉它该消息可以安全的删除了。假如客户端在发送ack之前意外死掉了，那么RabbitMQ会将消息投递到下一个consumer客户端。如果有多个consumer客户端，RabbitMQ在投递消息时是轮询的。
RabbitMQ如何判断客户端死掉了？唯一根据是客户端连接是否断开。这里没有超时机制，也就是说客户端可以处理一个消息很长时间，只要没断开连接，RabbitMQ就一直等待ack消息。
消息确认机制默认是打开的，除非你设置no_ack=True标记来手工关闭它。
消息消费者
1. 消费者配置并发消费者个数
如果消费者对消息的时序不是特别敏感，建议配置合适的并发消费者，增加消费能力，防止只有一个消费者阻塞时造成消息积压。
2. 消费者配置每次读取消费个数
跟上面的场景类似，配置prefetchCount，决定每次读取消息时，获取消息的个数，可以减少网络的传输次数，提高消费能力，但是会降低消息的时序性。
3. 消费者消费消息时不抛出异常
如果消费消息时抛出异常，则消息无法正常的ack，会重新放回队列，重新发送此消息，如果还无法消费，会一直重发，相当于死循环状态，影响后续的消息处理和整个MQ server的性能。
4. 评估消费能力
有一个基本原则是消费能力应该大于生产能力，否则就会造成消息的积压
MQ允许少量的消息积压，消息积压会降低MQserver的性能
大量的消费积压会触发报警，而且大量积压会触发内存流控，影响整个集群
消息生产者
1. 生产者实现消息发送失败重发
应用系统发送时，建议如果出错的话可以存储到本地数据库或文件系统，然后实现定时重发或手动重发。
