- 大纲

1、为什么使用消息队列

2、消息队列有什么优点和缺点

3、kafka、activemq、rabbitmq、rocketmq都有什么优点和缺点

1、为什么使用消息队列

1. 先说一下消息队列的常见使用场景吧，其实场景有很多，但是比较核心的有3个：解耦、异步、削峰

解耦： A系统发送个数据到BCD三个系统，接口调用发送，那如果E系统也要这个数据呢？那如果D系统现在不需要了呢？现在A系统又要发送第二种数据了呢？A系统负责人濒临各种修改代码崩溃中。。。然后又有更加崩溃的事，A系统要时时刻刻考虑BCDE四个系统如果挂了咋办？要不要重发？要不要把消息存起来？

不使用MQ的系统解耦场景图:

使用MQ之后的解耦场景图:

异步： A系统接收一个请求，需要在自己本地写库，还需要在BCD三个系统写库，自己本地写库要3ms，BCD三个系统分别写库要300ms、450ms、200ms。最终请求总延时是3 + 300 + 450 + 200 = 953ms，接近1s。系统响应就会很慢

不使用MQ,高延时同步场景图:

使用MQ异步化后的接口性能优化图:

削峰： 每天0点到11点，A系统风平浪静，每秒并发请求数量就100个。结果每次一到11点~1点，每秒并发请求数量突然会暴增到1万条。但是系统最大的处理能力就只能是每秒钟处理1000个请求,系统就可能会死

不使用MQ的时候高峰期系统被打死场景图:

使用MQ高峰期系统削峰场景图:

2、消息队列有什么优点和缺点

1. 优点上面已经说了，就是在特殊场景下有其对应的好处，解耦、异步、削
2. 缺点呢？显而易见:
3. 系统可用性降低：系统引入的外部依赖越多，越容易挂。如：MQ挂了，整套系统不可用
4. 系统复杂性提高：加了MQ进来，需要考虑怎么保证消息没有重复消费？怎么处理消息丢失的情况？怎么保证消息传递的顺序性？
5. 一致性问题：A系统处理完了直接返回成功了，人都以为你这个请求就成功了；但是问题是，要是BCD三个系统那里，BD两个系统写库成功了，结果C系统写库失败了，这数据就不一致了。

所以消息队列实际是一种非常复杂的架构，引入它有很多好处，但是也得针对它带来的坏处做各种额外的技术方案和架构来规避掉，之后，你会发现，系统复杂度提升了一个数量级，也许是复杂了10倍。但是关键时刻，还是得用的

3、kafka、activemq、rabbitmq、rocketmq都有什么优点和缺点

activemq最早企业都用ActiveMQ，但是现在企业确实用的不多了。没经过大规模吞吐量场景的验证，社区也不是很活跃，所以这里不对比

优劣总结：

1. RabbitMQ好处：
2. 0、基本不会丢数据
3. 1、吞吐量到万级，MQ功能比较完善、延时非常低（消息写到mq，到消费停留的时间）
4. 2、开源的管理界面，大量的操作可基于管理界面操作，包括创建queues、集群的监控等
5. 3、官方社区很活跃，几乎一个月发布几个版本。近几年比较企业使用的也比较多
6. ------------------
7. RabbitMQ劣势：
8. 0、吞吐量单机会低一些，因为它做的实现机制比较重
9. 1、erlang语言开发，很难看懂源码，企业很难定制和掌控，基本得依靠开源社区的快速维护和修复bug(不用到比较乱七八糟的功能，这个问题不大)
10. 2、集群动态扩展相对比RocketMq麻烦

1. RocketMQ好处：
2. 0、在阿里大规模应用过，日处理消息上百亿之多(阿里品牌保障)
3. 1、可以做到大规模吞吐、性能也非常好、分布式扩展很方便
4. 2、java源码开发，可以定制公司的MQ
5. 3、官方社区算活跃
6. ------------------
7. RocketMQ劣势：
8. 0、文档相对简单一些，接口不是按照JMS规范走的。有些系统要迁移需要修改大量代码
9. 1、阿里出台的技术，得做好这个技术万一被抛弃，官方停止维护得公司自己去维护或者靠社区修复一些bug

1. Kafka好处：
2. 0、仅仅提供较少的核心功能，但是提供超高的吞吐量
3. 1、ms级的延迟，极高的可用性以及可靠性，而且分布式可以任意扩展
4. 2、topic数量越少，保证其超高吞吐量
5. 3、大数据领域的实时计算、日志采集等场景，Kafka是业内标准，绝对不会黄
6. ------------------
7. Kafka劣势：
8. 0、topic从几十个到几百个的时候，吞吐量会大幅度下降
9. 1、有可能消息重复消费，那么对数据准确性会造成极其轻微的影响

个人建议：

1. ActiveMQ：不建议使用，没经过大规模吞吐量场景的验证，社区也不是很活跃，防止踩坑
2. Kafka: 如果是大数据领域的实时计算、日志采集等场景，用Kafka是业内标准
3. RabbitMQ:erlang语言开放，是由存大量个人散户，一般是不会黄，社区很活跃
4. RocketMQ:确实很不错，但是得想好社区万一突然黄掉的风险，对自己公司技术实力有绝对自信就推荐用RocketMQ

中小型公司技术挑战不是特别高，用RabbitMQ是不错的选择(吞吐量不错、功能也完备、管理后台方便、开源社区活跃。不一定要自己去看erlang源码，依靠社区快速迭代版本也是可以)

大型公司或者中大型公司，有基础架构研发实力，可以投入一组java的研发MQ源码，并可以进行改造，这种公司选择RocketMQ更合适，因为RocketMQ做的确实比RabbitMQ更好。（吞吐量、分布式等）

大数据领域的实时计算、日志采集等场景，kafka不用考虑