1.为什么使用消息队列？
（1）解耦：可以在多个系统之间进行解耦，将原本通过网络之间的调用的方式改为使用MQ进行消息的异步通讯，只要该操作不是需要同步的，就可以改为使用MQ进行不同系统之间的联系，这样项目之间不会存在耦合，系统之间不会产生太大的影响，就算一个系统挂了，也只是消息挤压在MQ里面没人进行消费而已，不会对其他的系统产生影响。
不使用MQ的情况.png
使用MQ进行解耦之后
（2）异步：加入一个操作设计到好几个步骤，这些步骤之间不需要同步完成，比如客户去创建了一个订单，还要去客户轨迹系统添加一条轨迹、去库存系统更新库存、去客户系统修改客户的状态等等。这样如果这个系统都直接进行调用，那么将会产生大量的时间，这样对于客户是无法接收的；并且像添加客户轨迹这种操作是不需要去同步操作的，如果使用MQ将客户创建订单时，将后面的轨迹、库存、状态等信息的更新全都放到MQ里面然后去异步操作，这样就可加快系统的访问速度，提供更好的客户体验。
不使用MQ情况
使用MQ进行异步之后
（3）削峰：一个系统访问流量有高峰时期，也有低峰时期，比如说，中午整点有一个抢购活动等等。比如系统平时流量并不高，一秒钟只有100多个并发请求，系统处理没有任何压力，一切风平浪静，到了某个抢购活动时间，系统并发访问了剧增，比如达到了每秒5000个并发请求，而我们的系统每秒只能处理2000个请求，那么由于流量太大，我们的系统、数据库可能就会崩溃。这时如果使用MQ进行流量削峰，将用户的大量消息直接放到MQ里面，然后我们的系统去按自己的最大消费能力去消费这些消息，就可以保证系统的稳定，只是可能要跟进业务逻辑，给用户返回特定页面或者稍后通过其他方式通知其结果。
使用MQ进行削峰
2.消息队列有什么优点和缺点？
优点：
- 对结构复杂、设计系统多的操作进行解耦操作，降低系统的操作复杂度、降低系统的维护成本。
- 对一个可以进行异步操作的一些系统操作进行异步，减小操作的响应时间，提供更好的用户体验。
- 可对高流量进行削峰，保证系统的平稳运行。
缺点：
- 系统可用性降低。比如在系统中引入MQ，那么万一MQ挂了怎么办呢？一般而言，引入的外部依赖越多，系统越脆弱，每一个依赖出问题都会导致整个系统的崩溃。
- 系统复杂度提高。需要考虑MQ的各种情况，比如：消息的重复消费、消息丢失、保证消费顺序等等.
- 数据一致性问题。比如A系统已经给客户返回操作成功，这时候操作BC都成功了，操作D却失败了，导致数据不一致。
3.kafka、activemq、rabbitmq、rocketmq都有什么优点和缺点啊？
综上所述：
一般业务系统要引入MQ，最早大家都用ActiveMQ，但现在用的不多了。没有经过大规模吞吐场景的验证，社区也不活跃，不推荐再使用。 后来大家开始用rabbitMQ，但是它是使用erlang语言开发的，如果不精通erlang，对公司而言，几乎处于不可控的状态，单其是开源的，社区活跃度高，拥有比较稳定的支持。 现在越来越多的公司开始使用RocketMQ，但是要小心被抛弃的风险。如果公司有实力自己去维护开发，推荐使用。否则还是选择RabbitMQ。 如果实在大数据的实时计算、日志采集等领域，用kafka是业界标准。
所以，对于中小型公司，技术实力一般的，应该用rabbitmq，对于大公司，基础架构研发能力强大的，推荐使用RocketMQ。
