关于ActiveMQ、RocketMQ、RabbitMQ、Kafka⼀些总结和区别这是⼀篇分享⽂
为什么写这篇⽂章?
博主有两位朋友分别是⼩A和⼩B:
1. ⼩A，⼯作于传统软件⾏业(某社保局的软件外包公司)，每天⼯作内容就是和产品聊聊需求，改改业务逻辑。再不然就是和运营聊聊天，写
⼏个SQL，⽣成下报表。⼜或者接到客服的通知，某某功能故障了，改改数据，然后下班部署上线。每天过的都是这种⽣活，技术零成长。
2. ⼩B，⼯作于某国企，虽然能接触到⼀些中间件技术。然⽽，他只会订阅/发布消息。通俗点说，就是调调API。对为什么使⽤这些中间件
啊？如何保证⾼可⽤啊？没有充分的认识。
庆幸的是两位朋友都很有上进⼼，于是博主写这篇⽂章，帮助他们复习⼀下关于消息队列中间件这块的要点
复习要点
本⽂⼤概围绕如下⼏点进⾏阐述:
1. 为什么使⽤？
2. 使⽤消息队列有什么缺点?
3. 如何选型?
4. 如何保证消息队列是⾼可⽤的？
5. 如何保证消息不被重复消费?
6. 如何保证消费的可靠性传输?
7. 如何保证消息的顺序性？
我们围绕以上七点进⾏阐述。需要说明⼀下，本⽂不是《消息队列从⼊门到精通》这种课程，因此只是提供⼀个复习思路，⽽不是去教你们怎么调⽤消息队列的API。建议对消息队列不了解的⼈，去点消息队列的博客看看，再看本⽂，收获更⼤
正⽂
1、为什么要使⽤?
分析:⼀个⽤消息队列的⼈，不知道为啥⽤，这就有点尴尬。没有复习这点，很容易被问蒙，然后就开始胡扯了。
回答：这个问题，咱只答三个最主要的应⽤场景(不可否认还有其他的，但是只答三个主要的)，即以下六个字：解耦、异步、削峰
(1)解耦
传统模式:
传统模式的缺点：
系统间耦合性太强，如上图所⽰，系统A在代码中直接调⽤系统B和系统C的代码，如果将来D系统接⼊，系统A还需要修改代码，过于⿇烦！
中间件模式:
中间件模式的的优点：
将消息写⼊消息队列，需要消息的系统⾃⼰从消息队列中订阅，从⽽系统A不需要做任何修改。
(2)异步
传统模式:
传统模式的缺点：
⼀些⾮必要的业务逻辑以同步的⽅式运⾏，太耗费时间。
中间件模式:
中间件模式的的优点：
将消息写⼊消息队列，⾮必要的业务逻辑以异步的⽅式运⾏，加快响应速度
(3)削峰
传统模式
传统模式的缺点：
并发量⼤的时候，所有的请求直接怼到数据库，造成数据库连接异常
中间件模式:
中间件模式的的优点：
系统A慢慢的按照数据库能处理的并发量，从消息队列中慢慢拉取消息。在⽣产中，这个短暂的⾼峰期积压是允许的。
2、使⽤了消息队列会有什么缺点?
分析:⼀个使⽤了MQ的项⽬，如果连这个问题都没有考虑过，就把MQ引进去了，那就给⾃⼰的项⽬带来了风险。我们引⼊⼀个技术，要对这个技术的弊端有充分的认识，才能做好预防。要记住，不要给公司挖坑！
回答：回答也很容易，从以下两个个⾓度来答
系统可⽤性降低：你想啊，本来其他系统只要运⾏好好的，那你的系统就是正常的。现在你⾮要加个消息队列进去，那消息队列挂了，你的系统不是呵呵了。因此，系统可⽤性降低
activemq集环境搭建
系统复杂性增加：要多考虑很多⽅⾯的问题，⽐如⼀致性问题、如何保证消息不被重复消费，如何保证保证消息可靠传输。因此，需要考虑的东西更多，系统复杂性增⼤。
但是，我们该⽤还是要⽤的。
3、消息队列如何选型?
先说⼀下，博主只会ActiveMQ,RabbitMQ,RocketMQ,Kafka，对什么ZeroMQ等其他MQ没啥理解，因此只能基于这四种MQ给出回答。
分析：既然在项⽬中⽤了MQ，肯定事先要对业界流⾏的MQ进⾏调研，如果连每种MQ的优缺点都没了解清楚，就拍脑袋依据喜好，⽤了某种MQ，还是给项⽬挖坑。如果⾯试官问:"你为什么⽤这种MQ？。"你直接回答"领导决定的。"这种回答就很LOW了。还是那句话，不要给公司挖坑。
回答:⾸先，咱先上，看看该MQ的更新频率:
1.
Apache ActiveMQ 5.15.3 Release
2.
Christopher L. Shannon posted on Feb 12, 2018
3.
Apache ActiveMQ 5.15.2 Released
4.
Christopher L. Shannon posted on Oct 23, 2017
5.
Apache ActiveMQ 5.15.0 Released
6.
Christopher L. Shannon posted on Jul 06, 2017
7.
省略以下记录
8.
...
我们可以看出，ActiveMq⼏个⽉才发⼀次版本，据说研究重⼼在他们的下⼀代产品Apollo。
接下来，我们再去去看⼀下,RabbitMQ的更新频率
1.
RabbitMQ 3.7.3 release 30 January 2018
2.
RabbitMQ 3.6.15 release 17 January 2018
3.
RabbitMQ 3.7.2 release23 December 2017
4.
RabbitMQ 3.7.1 release21 December 2017
5.
省略以下记录
6.
...
我们可以看出，RabbitMQ版本发布⽐ActiveMq频繁很多。⾄于RocketMQ和kafka就不带⼤家看了，总之也⽐ActiveMQ活跃的多。详情，可⾃⾏查阅。
再来⼀个性能对⽐表
特性ActiveMQ RabbitMQ RocketMQ kafka
开发
语⾔
java erlang java scala
单机
吞吐
量
万级万级10万级10万级
时效
性
ms级us级ms级ms级以内
可⽤性⾼(主从架构)⾼(主从架构)
⾮常⾼(分布
式架构)
⾮常⾼(分布式架构)
功能特性成熟的产品，在很多公司得到应
⽤；有较多的⽂档；各种协议⽀
持较好
基于erlang开发，所以并发能⼒很
强，性能极其好，延时很低；管理界
⾯较丰富
MQ功能⽐较
完备，扩展
性佳
只⽀持主要的MQ功能，像⼀些消息查询，消息回溯等
功能没有提供，毕竟是为⼤数据准备的，在⼤数据领
域应⽤⼴。
综合上⾯的材料得出以下两点:
(1)中⼩型软件公司，建议选RabbitMQ.⼀⽅⾯，erlang语⾔天⽣具备⾼并发的特性，⽽且他的管理界⾯⽤起来⼗分⽅便。正所谓，成也萧何，败也萧何！他的弊端也在这⾥，虽然RabbitMQ是开源的，然⽽国内有⼏个能定制化开发erlang的程序员呢？所幸，RabbitMQ的社区⼗分活跃，可以解决开发过程中遇到的bug，这点对于中⼩型公司来说⼗分重要。不考虑rocketmq和kafka的原因是，⼀⽅⾯中⼩型软件公司不如互联⽹公司，数据量没那么⼤，选消息中间件，应⾸选功能⽐较完备的，所以kafka排除。不考虑rocketmq的原因是，rocketmq是阿⾥出品，如果阿⾥放弃维护rocketmq，中⼩型公司⼀般抽不出⼈来进⾏rocketmq的定制化开发，因此不推荐。
(2)⼤型软件公司，根据具体使⽤在rocketMq和kafka之间⼆选⼀。⼀⽅⾯，⼤型软件公司，具备⾜够的资⾦搭建分布式环境，也具备⾜够⼤的数据量。针对rocketMQ,⼤型软件公司也可以抽出⼈⼿对rocketMQ进⾏定制化开发，毕竟国内有能⼒改JAVA源码的⼈，还是相当多的。⾄于kafka，根据业务场景选择，如果有⽇志采集功能，肯定是⾸选kafka了。具体该选哪个，看使⽤场景。
4、如何保证消息队列是⾼可⽤的？
分析：在第⼆点说过了，引⼊消息队列后，系统的可⽤性下降。在⽣产中，没⼈使⽤单机模式的消息队列。因此，作为⼀个合格的程序员，应该
对消息队列的⾼可⽤有很深刻的了解。如果⾯试的时候，⾯试官问，你们的消息中间件如何保证⾼可⽤
的？你的回答只是表明⾃⼰只会订阅和发布消息，⾯试官就会怀疑你是不是只是⾃⼰搭着玩，压根没在⽣产⽤过。请做⼀个爱思考，会思考，懂思考的程序员。
回答：这问题，其实要对消息队列的集模式要有深刻了解，才好回答。
以rcoketMQ为例，他的集就有多master 模式、多master多slave异步复制模式、多 master多slave同步双写模式。多master多slave模式部署架构图(⽹上的，偷个懒，懒得画):
其实博主第⼀眼看到这个图，就觉得和kafka好像，只是NameServer集，在kafka中是⽤zookeeper代替，都是⽤来保存和发现master和slave ⽤的。通信过程如下:
Producer 与 NameServer集中的其中⼀个节点（随机选择）建⽴长连接，定期从 NameServer 获取 Topic 路由信息，并向提供 Topic 服务的Broker Master 建⽴长连接，且定时向 Broker 发送⼼跳。Producer 只能将消息发送到 Broker master，但是 Consumer 则不⼀样，它同时和提供Topic 服务的 Master 和 Slave建⽴长连接，既可以从 Broker Master 订阅消息，也可以从 Broker Slave 订阅消息。
那么kafka呢，为了对⽐说明直接上kafka的拓补架构图(也是的，懒得画)
如上图所⽰，⼀个典型的Kafka集中包含若⼲Producer（可以是web前端产⽣的Page View，或者是服务器⽇志，系统CPU、Memory等），若⼲broker（Kafka⽀持⽔平扩展，⼀般broker数量越多，集吞吐率越⾼），若⼲Consumer Group，以及⼀个Zookeeper集。Kafka通过Zookeeper管理集配置，选举leader，以及在Consumer Group发⽣变化时进⾏rebalance。Producer使⽤push模式将消息发布到
broker，Consumer使⽤pull模式从broker订阅并消费消息。
⾄于rabbitMQ，也有普通集和镜像集模式，⾃⾏去了解，⽐较简单，两⼩时即懂。
要求，在回答⾼可⽤的问题时，应该能逻辑清晰的画出⾃⼰的MQ集架构或清晰的叙述出来。
5、如何保证消息不被重复消费？
分析：这个问题其实换⼀种问法就是，如何保证消息队列的幂等性?这个问题可以认为是消息队列领域的基本问题。换句话来说，是在考察你的设计能⼒，这个问题的回答可以根据具体的业务场景来答，没有固定的答案。
回答：先来说⼀下为什么会造成重复消费?
  其实⽆论是那种消息队列，造成重复消费原因其实都是类似的。正常情况下，消费者在消费消息时候，
消费完毕后，会发送⼀个确认信息给消息队列，消息队列就知道该消息被消费了，就会将该消息从消息队列中删除。只是不同的消息队列发送的确认信息形式不同，例如RabbitMQ是发送⼀个ACK确认消息，RocketMQ是返回⼀个CONSUME_SUCCESS成功标志，kafka实际上有个offset的概念，简单说⼀下(如果还不懂，出门⼀个kafka⼊门到精通教程)，就是每⼀个消息都有⼀个offset，kafka消费过消息后，需要提交offset，让消息队列知道⾃⼰已经消费过了。那造

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。