为什么要用消息队列（优点）
- 解耦：主要是消息中间件的发布订阅功能，多个模块可以订阅一个模块的消息，不过我从来没有做过相关的功能，而我接触到的主要是异步
- 异步：对于一次复杂操作可能需要耗时很长，这时候就可以对其进行时序性要求不高的功能进行拆分，通过发送消息来异步执行以提高系统响应速度
- 削峰：针对于大并发场景，大量请求到数据库对数据库造成压力，此时可以采用消息队列将请求信息缓存，然后按照数据库承受量对消息进行消费
带来的问题（缺点）
- 系统可用性降低：这个很好理解，如果消息服务挂掉，直接会导致整个依赖于消息服务的功能不可用，所以在设计系统时一定要考虑消息服务的高可用，从而提高系统的可用性。
- 系统一致性降低：这个是由于生产者发送消息成功后返回通知用户的是成功，而消费者在处理消息时失败了，这时候就会造成系统功能的不一致，所以设计时应该考虑消费失败的问题。
- 系统复杂性增高：没有引入时成功就是成功失败就是失败，引入后，就要考虑上面提到的一致性问题，可用性问题，还要考虑消息是否成功发送，消费者是否成功接收到消息这些属于消息的可靠投递问题，还有是否有重复消费的情况这属于幂等消费问题（即同一消息不管重复发送多少次都保证只能被消费一次）
主流消息队列产品
| 特性 | activemq | rabbitmq | rocketmq | kafka |
|---|---|---|---|---|
| 开发语言 | java | erlang | java | scala |
| 单机吞吐量 | 万级 | 万级 | 十万级 | 十万级 |
| 时效性 | 毫秒级 | 微妙级 | 毫秒级 | 毫秒级 |
| 可用性 | 高，主从架构 | 高，主从架构 | 非常高，分布式 | 非常高，分布式 |
| 消息丢失 | 低 | 低 | 通过参数配置0丢失 | 通过参数配置0丢失 |
| 功能支持 | MQ 领域的功能极其完备 | 基于 erlang 开发，并发能力很强，性能极好，延时很低 | MQ 功能较为完善，还是分布式的，扩展性好 | 功能较为简单，主要支持简单的 MQ 功能，在大数据领域的实时计算以及日志采集被大规模使用 |
看了很多网上的建议，中小型公司一般建议选择rabbitmq，因为其开源社区且活跃，不会出现太大问题，这样考虑也不无道理，反正我现在的公司也是在用rabbitmq，不过我感觉rocketmq会更好一些，等找时间好好学习一下。