1-核心功能
[TOC]
1.1-MQ介绍
1.1.1-作用
消息队列是一种“先进先出”的数据结构
当 Producer 想要把消息发送给 consumer，原始的方法是使用网络面对面提交，这样两个系统之间的耦合比较高， 消息队列的出现就是为了解耦
应用解耦
系统的耦合性越高，容错性就越低。以电商应用为例，用户创建订单后，如果耦合调用库存系统、物流系统、支付系统，任何一个子系统出了故障或者因为升级等原因暂时不可用，都会造成下单操作异常，影响用户使用体验。
使用消息队列解耦合，系统的耦合性就会提高了。比如物流系统发生故障，需要几分钟才能来修复，在这段时间内，物流系统要处理的数据被缓存到消息队列中，用户的下单操作正常完成。当物流系统回复后，补充处理存在消息队列中的订单消息即可，终端系统感知不到物流系统发生过几分钟故障。
流量削峰
应用系统如果遇到系统请求流量的瞬间猛增，有可能会将系统压垮。如果直接拒绝请求会让影响用户体验，有了消息队列可以将大量请求缓存起来，分散到很长一段时间处理。
数据分发
1.1.2-注意事项
缺点：
- 系统可用性降低
- 系统更复杂（你要学的技术更多了）
- 新技术面对的新挑战：数据同步
1.1.3-MQ产品对比
| 特性 | ActiveMQ | RabbitMQ | RocketMQ | Kafka |
|---|---|---|---|---|
| 单机吞吐量 | 万级，吞吐量比RocketMQ和Kafka要低一个数量级 | 万级，吞吐量比RocketMQ和Kafka要低一个数量级 | 十万级，RocketMQ也是可以支撑高吞吐的一种MQ | 十万级别，Kafka最大优点就是吞吐量大，一般配合大数据类的系统来进行实时数据计算、日志采集等场景 |
| Topic数量对吞吐量的影响 | - | - | Topic可以达到几百、几千个的级别，吞吐量会有小幅度的下降。这是RocketMQ的一大优势，可在同等数量机器下支撑大量的Topic | Topic从几十个到几百个的时候，吞吐量会大幅下降。所以在同等机器数量下，Kafka尽量保证Topic数量不要过多。如果支撑大规模Topic需要增加更多的机器 |
| 时效性 | ms级 | 微秒级，这是rabbitmq的一大特点，延迟是最低的 | ms级 | 延迟在ms级以内 |
| 可用性 | 高，基于主从架构实现可用性 | 高，基于主从架构实现可用性 | 非常高，分布式架构 | 非常高，Kafka是分布式的，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用 |
| 消息可靠性 | 有较低的概率丢失数据 | - | 经过参数优化配置，可以做到零丢失 | 经过参数配置，消息可以做到零丢失 |
| 功能支持 | MQ领域的功能及其完备 | 基于erlang开发，所以并发性能极强，性能极好，延时低 | MQ功能较为完备，分布式扩展性好 | 功能较为简单，主要支持加单MQ功能 |
| 优势 | 非常成熟，功能强大，在业内大量公司和项目中都有应用 | erlang语言开发，性能极好、延时很低，吞吐量万级、MQ功能完备，管理界面非常好，社区活跃；互联网公司使用较多 | 接口简单易用，阿里出品有保障，吞吐量大，分布式扩展方便、社区比较活跃，支持大规模的Topic、支持复杂的业务场景，可以基于源码进行定制开发 | 超高吞吐量，ms级的时延，极高的可用性和可靠性，分布式扩展方便 |
| 劣势 | 偶尔有较低概率丢失消息，社区活跃度不高 | 吞吐量较低，erlang语音开发不容易进行定制开发，集群动态扩展麻烦 | 接口不是按照标准JMS规范走的，有的系统迁移要修改大量的代码，技术有被抛弃的风险 | 有可能进行消息的重复消费 |
| 应用 | 主要用于解耦和异步，较少用在大规模吞吐的场景中 | 都有使用 | 用于大规模吞吐、复杂业务中 | 在大数据的实时计算和日志采集中被大规模使用，是业界的标准 |
总结
一般业务系统要引入 MQ，最早大家都用 ActiveMQ，但现在用的不多了。没有经过大规模吞吐场景的验证，社区也不活跃，不推荐再使用。后来大家开始用 RabbitMQ，但是它是使用 erlang 语言开发的，如果不精通 erlang，对公司而言，几乎处于不可控的状态，单其是开源的，社区活跃度高，拥有比较稳定的支持。现在越来越多的公司开始使用 RocketMQ，但是要小心被抛弃的风险。如果公司有实力自己去维护开发，推荐使用，否则还是选择 RabbitMQ。如果实在大数据的实时计算、日志采集等领域，用 Kafka 是业界标准。
所以，对于中小型公司，技术实力一般的，应该用 Rabbitmq，对于大公司，基础架构研发能力强大的，推荐使用 RocketMQ