资料内容：
一、MQ介绍
MQ（Message Queue）消息队列,是 “先进先出” 的一种数据结构。
二、MQ的使用
MQ 一般用来解决应用解耦，异步处理，流量削峰等问题，实现高性能，高可用，可伸缩和最终一致性架构。
1应用解耦
当 A 系统生产关键数据，发送数据给多个其他系统消费，此时 A 系统和其他系统产生了严重的耦合。
如果将 A 系统产生的数据放到 MQ 当中，其他系统去 MQ 获取消费数据，此时各系统独立运行只与 MQ 交互，
添加新系统消费， A 系统的数据也不需要去修改 A 系统的代码，达到了解耦的效果。
2异步处理
互联网类企业对用户的直接操作，一般要求每个请求在 200ms 以内完成。对于一个系统调用多个系统，不使用 MQ 的情况下，它执行完返回的耗时是调用完所有系统所需时间的总和；使用 MQ 进行优化后，执行的耗时则是执行主系统的耗时
加上发送数据到消息队列的耗时，大幅度提升系统性能和用户体验。
3流量削峰
MySQL 每秒最高并发请求在 2000 左右，用户访问量高峰期的时候涌入的大量请求，会将 MySQL 打死，然后系统就挂掉，但过了高峰期，请求量可能远低于 2000，这种情况去增加服务器就不值得，
如果使用 MQ 的情况，将用户的请求全部放到 MQ 中，让系统去消费用户的请求，不要超过系统所能承受的最大请求数量，保证系统不会再高峰期挂掉，高峰期过后系统还是按照最大请求数量处理完请求。
4日志处理
日志采集方收集日志写入 kafka 的消息队列中，处理方订阅并消费 kafka 队列中的日志数据。
5消息通讯
点对点或者订阅发布模式，通过消息进行通讯。如微信的消息发送与接收、聊天室等。
三、使用 MQ 的缺陷
1.系统可用性降低：
以前只要担心系统的问题，现在还要考虑 MQ 挂掉的问题，MQ 挂掉，所关联的系统都会无法提供服务。
2.系统复杂性变高
要考虑消息丢失、消息重复消费等问题。
3.一致性问题
多个 MQ 消费系统，部分成功，部分失败，要考虑事务问题。
四、常用的 MQ
ActiveMQ：
支持万级的吞吐量，较成熟完善；官方更新迭代较少，社区的活跃度不是很高，有消息丢失的情况。
RabbitMQ：
延时低，微妙级延时，社区活跃度高，bug 修复及时，而且提供了很友善的后台界面；用 Erlang 语言开发，只熟悉 Java 的无法阅读源码和自行修复 bug。
RocketMQ：
阿里维护的消息中间件，可以达到十万级的吞吐量，支持分布式事务。
Kafka：
分布式的中间件，最大优点是其吞吐量高，一般运用于大数据系统的实时运算和日志采集的场景，功能简单，可靠性高，扩展性高；
缺点:可能导致重复消费。
