工作中使用的是RabbitMQ，需要对其进行熟悉。使用之前，弄清楚它是什么东西，解决什么问题。
场景
一些不必实时执行的任务
开发中，有一些任务并无须实时执行，比如：
- 会员更新个人信息，更新会员信息之余，需写一笔日志记录到日志表
- 会员升级了，更新会员等级表，而后需发送一封邮件通知会员
如上，保存日志表、发送邮件等任务的实时性并不强，在系统繁忙时有可能阻塞，堵塞容易导致任务失败。
如果我们把它们放入队列中，轮候执行，减低耦合的同时，是不是也缓解了系统压力。
发布和订阅
系统开发中，缓存的运用缓解了数据库原始数据读的压力。一般来说，系统有多份缓存。如果数据库记录发生更新，需要通知各缓存更新最新记录时，队列发布和订阅模式就发挥作用了。
角色介绍
生产者
生产：将消息发送到队列。发送消息的程序，称为生产者。
队列
生产者发送的消息到达队列，队列是一个缓冲区，暂存消息，消息最终会转发给消费者。
可以想象队列就是邮局，只不过邮局处理的是信件，RabbitMQ处理的是二进制的消息。
消费者
消费，从队列中获取消息，并处理消息。消费消息的程序，称为消费者。
交换器
交换器是介于生产者、队列之间，交换器按“路由策略”将消息路由到队列中，而路由策略有几种：direct、fanout、topic、headers。
简要介绍前两个：
direct，将消息发布到名称与路由键匹配的队列中。fanout，将消息发布到与此交换器绑定的队列中。
消息的流向
消息的流向：生产者>交换器>队列>消费者。
模式
任务队列（一个消息对应一个消费者）
任务队列，为了避免实时执行资源密集型的任务，我们把要做的任务，封装成消息放入队列，工作线程在后台运行并执行这些任务。
发布和订阅
在发布/订阅模式中，有一个生产者和两个消费者，生产者发送A消息，两个消费者均需接受到消息。
其他
声明队列的时机
生产者向队列发送消息，消费者监听队列等待消息，所以，在发送消息和消费消息前要声明队列。
大多数情况，我们不能确定生产者还是消费者谁先启动，所以，我们在两者中都作声明，RabbitMQ允许对相同队列相同参数作重复声明，即对于二次声明动作不做操作。
如果对同一队列名不同参数作二次声明，会返回错误。
消息确认机制
为了保证消息不丢失，RabbitMQ有消息确认机制，消息确认机制默认是开启的。
当消费者接收消息并处理完毕，需发送一个确认给RabbitMQ，RabbitMQ就会从队列中删除此消息。
RabbitMQ允许消费者处理消息任意长的时间，只有消费者退出了，RabbitMQ才会将消息重新轮候，不存在超时重新轮候的情况。
如果忘了确认，或确认过程中失败了，消息会在消费者退出后，RabbitMQ才将消息重新轮候。RabbitMQ会因不能释放未确认的消息而消耗更多空间，如何查看未确认的消息，请搜索messages_unacknowledged。
消息持久化
如果消费者宕机，我们通过消息确认机制寻回消息，如果RabbitMQ宕机，为了避免丢失消息，我们要设置消息持久化：
- 声明队列是持久的
- 标记消息是持久的
注意：此方法严格来说不能完全保证消息不会丢失，仍存在很短的时间间隙于RabbitMQ接收了消息但未写磁盘。如果需要更强的机制保证，要使用publisher confirms（本文不作讨论）。
消息分发
默认情况下，RabbitMQ采用循环的方式将消息发送给消费者。
有时，每个消息对系统的消耗不同，有些消息很快处理，有些则需花相当一段时间，所以，我们经常用basicQos(int n)方法告诉RabbitMQ不要同时分配多于n个消息给同一消费者。比如设置basicQos(1)，就是在消费者未确认消息前，不要给它分配下一个消息。