为什么使用消息中间件？消息队列核心使用场景<优点>：解耦、异步、削峰
(1)解耦
传统模式:
传统模式的缺点：
- 系统间耦合性太强，如上图所示，系统A在代码中直接调用系统B和系统C的代码，如果将来D系统接入，系统A还需要修改代码，过于麻烦！
中间件模式:
中间件模式的的优点：
- 将消息写入消息队列，需要消息的系统自己从消息队列中订阅，从而系统A不需要做任何修改。
(2)异步
传统模式:
传统模式的缺点：
- 一些非必要的业务逻辑以同步的方式运行，太耗费时间。
中间件模式:
中间件模式的的优点：
- 将消息写入消息队列，非必要的业务逻辑以异步的方式运行，加快响应速度
(3)削峰
传统模式
传统模式的缺点：
- 并发量大的时候，所有的请求直接怼到数据库，造成数据库连接异常
中间件模式:
中间件模式的的优点：
- 系统A慢慢的按照数据库能处理的并发量，从消息队列中慢慢拉取消息。在生产中，这个短暂的高峰期积压是允许的。
消息中间件缺点有哪些？
-
系统可用性降低
系统引入的外部依赖越多，越容易挂掉，需要保证消息队列的高可用。 -
系统复杂度提高
多一个 MQ 组件，那就需要面对 消息没有重复消费，处理消息丢失的情况，保证消息传递的顺序性等等系统级别问题。 -
一致性问题
多个消费者消费某一个消息就可能出现个别消费失败的情况，会出现数据不一致。
ActiveMQ、RabbitMQ、RocketMQ、Kafka 有什么优缺点？
| 特性 | ActiveMQ | RabbitMQ | RocketMQ | Kafka |
|---|---|---|---|---|
| 单机吞吐量 | 万级 比RocketMQ、Kafka 低一个数量级 | 同ActiveMQ | 10 万级，支撑高吞吐 | 10 万级 高吞吐，一般配合大数据类的系统来进行实时数据计算、日志采集等场景 |
| topic 数量对吞吐量的影响 | topic可以达到几百/几千的级别，吞吐量会有较小幅度的下降，这是 RocketMQ 的一大优势，在同等机器下，可以支撑大量的 topic | topic 从几十到几百个时候，吞吐量会大幅度下降，在同等机器下，Kafka 尽量保证 topic 数量不要过多，如果要支撑大规模的 topic，需要增加更多的机器资源 | ||
| 时效性 | ms 级 | 微秒级 这是RabbitMQ的一大特点 延迟最低 | ms 级 | 延迟在 ms 级以内 |
| 可用性 | 高 基于主从架构实现高可用 | 同 ActiveMQ | 非常高，分布式架构 | 非常高，分布式，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用 |
| 消息可靠性 | 有较低的概率丢失数据 | 基本不丢 | 经过参数优化配置，可以做到 0 丢失 | 同 RocketMQ |
| 功能支持 | MQ 领域的功能极其完备 | 基于 erlang 开发，并发能力很强，性能极好，延时很低 | MQ 功能较为完善，还是分布式的，扩展性好 | 功能较为简单，主要支持简单的 MQ 功能，在大数据领域的实时计算以及日志采集被大规模使用 |
总结：最早大家都使用ActiveMQ，未经过大规模吞吐量场景的验证，目前很少使用；
RabbitMQ：中小型公司，技术实力较为一般，技术挑战不是特别高；
RocketMQ：大型公司，基础架构研发实力较强；
Kafka：大数据领域的实时计算、日志采集等场景
来源：oschina
链接：https://my.oschina.net/AnniHome/blog/3164797