一、项目架构中引入MQ的优劣（假想接口操作为写库）
- 优势，主要有3方面：
- 解耦：如果A服务的一个接口需要调用B、C、D、E…..系统的对应接口，将数据推送给其它系统，如果采用接口调用，这需要在A的接口中同步（或异步线程）调用其它系统接口。
如果后续其中某一个系统不需要这个数据了，则需要修改A服务的接口；而且A服务需要考虑如果数据没有推送到其它系统或个别系统的接口调用超时等情况，需要采取什么措施进行弥补，系统之间耦合性很高。采用MQ，A服务只需要将数据成功推送给MQ后，就不用关心谁去消费它，降低系统之间的耦合性。 - 异步：场景同上，假设A本身接口调用时间50ms，B、C、D、E…接口调用时间为200ms、240ms、200ms、100ms….那么A接口调用响应时间至少为790ms，响应时间要比本接口响应时间高很多，如果这些接口本身不需要同步调用，即A服务不需要关心其它系统的接口调用结果，此时将数据成功推送到MQ之后，A服务该接口就可以直接返回，可以降低系统接口的响应时间，提高系统的响应能力。
- 削峰：假设A服务某接口平时每秒并发为500，系统承受最大并发为1000，但是在特定时间，系统的每秒并发在2000，系统承受不了这么多的并发，很容易造成系统瘫痪。如果采用MQ进行请求排队，设定系统每秒处理消息数，可以降低系统瘫痪的可能性。
- 解耦：如果A服务的一个接口需要调用B、C、D、E…..系统的对应接口，将数据推送给其它系统，如果采用接口调用，这需要在A的接口中同步（或异步线程）调用其它系统接口。
- 劣势，主要有3方面：
- 系统可用性降低：原来系统只有A、B、C、D、E….系统，只需要保证他们的可用性就行了，但是现在引入了MQ后，又需要确保MQ的高可用，否则系统就不能正常提供服务。
- 系统复杂性提高：原来的系统之间直接进行接口调用就行了，现在引入了MQ之后，需要学习使用MQ的API，还需要额外部署MQ实例，还要考虑MQ的高可用、如何防止消息的重复消费、如何保证消息的正确投递和保证消费以及消息传递的顺序性……
- 一致性问题：以前A服务直接调用其它系统的接口，可以拿到同步结果，知道其它系统的处理结果，此时整体系统的数据是一致的。引入MQ之后，A服务成功推送数据到MQ，但是不知道其它系统是否处理了、即使处理了但是也不知道是否成功，如果没有处理或者没有处理成功，那此时的数据和没有引入MQ之前的数据出现了不一致。
二、现在主流的MQ之间区别
| 特性 | ActiveMQ | RabbitMQ | RocketMQ | Kafka |
|---|---|---|---|---|
| 单机吞吐量 | 万级 | 万级 | 10万级，RocketMQ也是可以支撑高吞吐的一种MQ | 10万级别，这是kafka最大的优点，就是吞吐量高。 |
| topic数量对吞吐量的影响 | topic可以达到几百，几千个的级别，吞吐量会有较小幅度的下降；这是RocketMQ的一大优势，在同等机器下，可以支撑大量的topic | topic从几十个到几百个的时候，吞吐量会大幅度下降；所以在同等机器下，kafka尽量保证topic数量不要过多。如果要支撑大规模topic，需要增加更多的机器资源 | ||
| 时效性 | ms级 | 微秒级，这是rabbitmq的一大特点，延迟是最低的 | ms级 | 延迟在ms级以内 |
| 可用性 | 高，基于主从架构实现高可用性 | 高，基于主从架构实现高可用性 | 非常高，分布式架构 | 非常高，kafka是分布式的，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用 |
| 消息可靠性 | 有较低的概率丢失数据 | 经过参数优化配置，可以做到0丢失 | 经过参数优化配置，可以做到0丢失 | |
| 功能支持 | MQ领域的功能极其完 | 基于erlang开发，所以并发能力很强，性能极其好，延时很低，功能较为完善 | MQ功能较为完善，还是分布式的，扩展性好 | 早期版本功能较为简单，主要支持简单的MQ功能，在大数据领域的实时计算以及日志采集被大规模使用，是事实上的标准 |
| 优劣势总结 | 非常成熟，功能强大，在业内大量的公司以及项目中都有应用；偶尔会有较低概率丢失消息；而且现在社区以及国内应用都越来越少，官方社区现在对ActiveMQ 5.x维护越来越少，几个月才发布一个版本；而且确实主要是基于解耦和异步来用的，较少在大规模吞吐的场景中使用 | erlang语言开发，性能极其好，延时很低；吞吐量到万级，MQ功能比较完备；而且开源提供的管理界面非常棒，用起来很好用；社区相对比较活跃，几乎每个月都发布几个版本分；在国内一些互联网公司近几年用rabbitmq也比较多一些；但是问题也是显而易见的，RabbitMQ确实吞吐量会低一些，这是因为他做的实现机制比较重。而且erlang开发，国内有几个公司有实力做erlang源码级别的研究和定制？如果说你没这个实力的话，确实偶尔会有一些问题，你很难去看懂源码，你公司对这个东西的掌控很弱，基本职能依赖于开源社区的快速维护和修复bug。而且rabbitmq集群动态扩展会很麻烦，不过这个我觉得还好。其实主要是erlang语言本身带来的问题。很难读源码，很难定制和掌控。 | 接口简单易用，而且毕竟在阿里大规模应用过，有阿里品牌保障；日处理消息上百亿之多，可以做到大规模吞吐，性能也非常好，分布式扩展也很方便，社区维护还可以，可靠性和可用性都是ok的，还可以支撑大规模的topic数量，支持复杂MQ业务场景；而且一个很大的优势在于，阿里出品都是java系的，我们可以自己阅读源码，定制自己公司的MQ，可以掌控；社区活跃度相对较为一般，不过也还可以，文档相对来说简单一些，然后接口这块不是按照标准JMS规范走的有些系统要迁移需要修改大量代码；还有就是阿里出台的技术，你得做好这个技术万一被抛弃，社区黄掉的风险，那如果你们公司有技术实力我觉得用RocketMQ挺好的 | kafka的特点其实很明显，就是仅仅提供较少的核心功能，但是提供超高的吞吐量，ms级的延迟，极高的可用性以及可靠性，而且分布式可以任意扩展；同时kafka最好是支撑较少的topic数量即可，保证其超高吞吐量；而且kafka唯一的一点劣势是有可能消息重复消费，那么对数据准确性会造成极其轻微的影响，在大数据领域中以及日志采集中，这点轻微影响可以忽略；这个特性天然适合大数据实时计算以及日志收集 |
综上进行，个人倾向：
一般的业务系统在选择MQ的时候，早期选用的大多数都是ActiveMQ，但是其社区不够活跃，随之大家开始使用RabbitMQ，虽然RabbitMQ是开源的，社区活跃度也高，但是因为采用erlang语言开发，对于java工程师深入研究还是带来了不小的阻碍。最近这几年国内的公司大多数都开始尝试使用RocketMQ，据了解阿里双11内部的消息队列就是基于RocketMQ优化的，经历过大规模并发测试。而kafka基本都是用于大数据领域的实时计算、日志采集等场景。
所以小公司，技术研究能力较为一般的，采用RabbitMQ也是不错的选择，社区支持和文档都不错，国内也有不少大规模使用的案例；而对于中大型公司，架构人员以及研发人员都有着不弱实力，尝试使用RocketMQ是更好的选择。针对于大数据等场景，基本不用考虑，直接采用Kakfa。
