消息队列：ActiveMQ、RabbitMQ、RocketMQ、Kafka
目录html
一、为何要使用消息队列？ 前端
（1）解耦java
（2）异步 程序员
（3）削峰 web
三、消息队列如何选型? redis
五、如何保证消息不被重复消费？ 数据库
六、如何保证消费的可靠性传输?apache
一、为何要使用消息队列？
分析:一个用消息队列的人，不知道为啥用，这就有点尴尬。没有复习这点，很容易被问蒙，而后就开始胡扯了。
这个问题,咱只答三个最主要的应用场景(不能否认还有其余的，可是只答三个主要的),即如下六个字:解耦、异步、削峰
（1）解耦
A 传统模式:
传统模式的缺点：系统间耦合性太强，如上图所示，系统A在代码中直接调用系统B和系统C的代码，若是未来D系统接入，系统A还须要修改代码，过于麻烦！
B 中间件模式:
中间件模式的的优势：将消息写入消息队列，须要消息的系统本身从消息队列中订阅，从而系统A不须要作任何修改。
（2）异步
A 传统模式:
传统模式的缺点： 一些非必要的业务逻辑以同步的方式运行，太耗费时间。
B 中间件模式:
中间件模式的的优势：将消息写入消息队列，非必要的业务逻辑以异步的方式运行，加快响应速度
（3）削峰
A 传统模式：
传统模式的缺点：并发量大的时候，全部的请求直接怼到数据库，形成数据库链接异常
B 中间件模式:
中间件模式的的优势：系统A慢慢的按照数据库能处理的并发量，从消息队列中慢慢拉取消息。 在生产中，这个短暂的高峰期积压是容许的。
二、使用了消息队列会有什么缺点?
分析:一个使用了MQ的项目，若是连这个问题都没有考虑过，就把MQ引进去了，那就给本身的项目带来了风险。咱们引入一个技术，要对这个技术的弊端有充分的认识，才能作好预防。要记住，不要给公司挖坑！
回答也很容易，从如下两个个角度来答
系统可用性下降：你想啊，原本其余系统只要运行好好的，那你的系统就是正常的。如今你非要加个消息队列进去，那消息队列挂了，你的系统不是呵呵了。所以，系统可用性下降
系统复杂性增长：要多考虑不少方面的问题，好比一致性问题、如何保证消息不被重复消费，如何保证保证消息可靠传输。所以，须要考虑的东西更多，系统复杂性增大。
可是，咱们该用仍是要用的。
三、消息队列如何选型?
先说一下，博主只会ActiveMQ,RabbitMQ,RocketMQ,Kafka，对什么ZeroMQ等其余MQ没啥理解，所以只能基于这四种MQ给出回答。
分析:既然在项目中用了MQ，确定事先要对业界流行的MQ进行调研，若是连每种MQ的优缺点都没了解清楚，就拍脑壳依据喜爱，用了某种MQ，仍是给项目挖坑。若是面试官问:"你为何用这种MQ？。"你直接回答"领导决定的。"这种回答就很LOW了。仍是那句话，不要给公司挖坑。
回答:首先，咱先上ActiveMQ的社区，看看该MQ的更新频率:
Apache ActiveMQ 5.15.3 Release
Christopher L. Shannon posted on Feb 12, 2018
Apache ActiveMQ 5.15.2 Released
Christopher L. Shannon posted on Oct 23, 2017
Apache ActiveMQ 5.15.0 Released
Christopher L. Shannon posted on Jul 06, 2017
省略如下记录
...
咱们能够看出，ActiveMq几个月才发一次版本，听说研究重心在他们的下一代产品Apollo。
接下来，咱们再去RabbitMQ的社区去看一下,RabbitMQ的更新频率
RabbitMQ 3.7.3 release 30 January 2018
RabbitMQ 3.6.15 release 17 January 2018
RabbitMQ 3.7.2 release23 December 2017
RabbitMQ 3.7.1 release21 December 2017
省略如下记录
...
咱们能够看出，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了。具体该选哪一个，看使用场景。
四、如何保证消息队列是高可用的？
分析:在第二点说过了，引入消息队列后，系统的可用性降低。在生产中，没人使用单机模式的消息队列。所以，做为一个合格的程序员，应该对消息队列的高可用有很深入的了解。若是面试的时候，面试官问，大家的消息中间件如何保证高可用的？你的回答只是代表本身只会订阅和发布消息，面试官就会怀疑你是否是只是本身搭着玩，压根没在生产用过。请作一个爱思考，会思考，懂思考的程序员。
回答:这问题，其实要对消息队列的集群模式要有深入了解，才好回答。
以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集群架构或清晰的叙述出来。
五、如何保证消息不被重复消费？
分析:这个问题其实换一种问法就是，如何保证消息队列的幂等性?这个问题能够认为是消息队列领域的基本问题。换句话来讲，是在考察你的设计能力，这个问题的回答能够根据具体的业务场景来答，没有固定的答案。
回答:先来讲一下为何会形成重复消费?
其实不管是那种消息队列，形成重复消费缘由其实都是相似的。正常状况下，消费者在消费消息时候，消费完毕后，会发送一个确认信息给消息队列，消息队列就知道该消息被消费了，就会将该消息从消息队列中删除。只是不一样的消息队列发送的确认信息形式不一样,例如RabbitMQ是发送一个ACK确认消息，RocketMQ是返回一个CONSUME_SUCCESS成功标志，kafka实际上有个offset的概念，简单说一下(若是还不懂，出门找一个kafka入门到精通教程),就是每个消息都有一个offset，kafka消费过消息后，须要提交offset，让消息队列知道本身已经消费过了。那形成重复消费的缘由?，就是由于网络传输等等故障，确认信息没有传送到消息队列，致使消息队列不知道本身已经消费过该消息了，再次将该消息分发给其余的消费者。
如何解决?这个问题针对业务场景来答分如下几点
(1)好比，你拿到这个消息作数据库的insert操做。那就容易了，给这个消息作一个惟一主键，那么就算出现重复消费的状况，就会致使主键冲突，避免数据库出现脏数据。
(2)再好比，你拿到这个消息作redis的set的操做，那就容易了，不用解决，由于你不管set几回结果都是同样的，set操做原本就算幂等操做。
(3)若是上面两种状况还不行，上大招。准备一个第三方介质,来作消费记录。以redis为例，给消息分配一个全局id，只要消费过该消息，将<id,message>以K-V形式写入redis。那消费者开始消费前，先去redis中查询有没消费记录便可。
六、如何保证消费的可靠性传输?
分析:咱们在使用消息队列的过程当中，应该作到消息不能多消费，也不能少消费。若是没法作到可靠性传输，可能给公司带来千万级别的财产损失。一样的，若是可靠性传输在使用过程当中，没有考虑到，这不是给公司挖坑么，你能够拍拍屁股走了，公司损失的钱，谁承担。仍是那句话，认真对待每个项目，不要给公司挖坑。
回答:其实这个可靠性传输，每种MQ都要从三个角度来分析:生产者弄丢数据、消息队列弄丢数据、消费者弄丢数据
RabbitMQ
(1)生产者丢数据
从生产者弄丢数据这个角度来看，RabbitMQ提供transaction和confirm模式来确保生产者不丢消息。
transaction机制就是说，发送消息前，开启事物(channel.txSelect())，而后发送消息，若是发送过程当中出现什么异常，事物就会回滚(channel.txRollback())，若是发送成功则提交事物(channel.txCommit())。
然而缺点就是吞吐量降低了。所以，按照博主的经验，生产上用confirm模式的居多。一旦channel进入confirm模式，全部在该信道上面发布的消息都将会被指派一个惟一的ID(从1开始)，一旦消息被投递到全部匹配的队列以后，rabbitMQ就会发送一个Ack给生产者(包含消息的惟一ID)，这就使得生产者知道消息已经正确到达目的队列了.若是rabiitMQ没能处理该消息，则会发送一个Nack消息给你，你能够进行重试操做。处理Ack和Nack的代码以下所示（说好不上代码的，偷偷上了）:
channel.addConfirmListener(new ConfirmListener() {
@Override
public void handleNack(long deliveryTag, boolean multiple) throws IOException {
System.out.println("nack: deliveryTag = "+deliveryTag+" multiple: "+multiple);
}
@Override
public void handleAck(long deliveryTag, boolean multiple) throws IOException {
System.out.println("ack: deliveryTag = "+deliveryTag+" multiple: "+multiple);
}
});
(2)消息队列丢数据
处理消息队列丢数据的状况，通常是开启持久化磁盘的配置。这个持久化配置能够和confirm机制配合使用，你能够在消息持久化磁盘后，再给生产者发送一个Ack信号。这样，若是消息持久化磁盘以前，rabbitMQ阵亡了，那么生产者收不到Ack信号，生产者会自动重发。
那么如何持久化呢，这里顺便说一下吧，其实也很容易，就下面两步
一、将queue的持久化标识durable设置为true,则表明是一个持久的队列
二、发送消息的时候将deliveryMode=2
这样设置之后，rabbitMQ就算挂了，重启后也能恢复数据
(3)消费者丢数据
消费者丢数据通常是由于采用了自动确认消息模式。这种模式下，消费者会自动确认收到信息。这时rahbitMQ会当即将消息删除，这种状况下若是消费者出现异常而没能处理该消息，就会丢失该消息。
至于解决方案，采用手动确认消息便可。
kafka
这里先引一张kafka Replication的数据流向图
Producer在发布消息到某个Partition时，先经过ZooKeeper找到该Partition的Leader，而后不管该Topic的Replication Factor为多少（也即该Partition有多少个Replica），Producer只将该消息发送到该Partition的Leader。Leader会将该消息写入其本地Log。每一个Follower都从Leader中pull数据。
针对上述状况，得出以下分析
(1)生产者丢数据
在kafka生产中，基本都有一个leader和多个follwer。follwer会去同步leader的信息。所以，为了不生产者丢数据，作以下两点配置第一个配置要在producer端设置acks=all。这个配置保证了，follwer同步完成后，才认为消息发送成功。
在producer端设置retries=MAX，一旦写入失败，这无限重试
(2)消息队列丢数据
针对消息队列丢数据的状况，无外乎就是，数据还没同步，leader就挂了，这时zookpeer会将其余的follwer切换为leader,那数据就丢失了。针对这种状况，应该作两个配置。
replication.factor参数，这个值必须大于1，即要求每一个partition必须有至少2个副本
min.insync.replicas参数，这个值必须大于1，这个是要求一个leader至少感知到有至少一个follower还跟本身保持联系
这两个配置加上上面生产者的配置联合起来用，基本可确保kafka不丢数据
(3)消费者丢数据
这种状况通常是自动提交了offset，而后你处理程序过程当中挂了。kafka觉得你处理好了。再强调一次offset是干吗的
offset：指的是kafka的topic中的每一个消费组消费的下标。简单的来讲就是一条消息对应一个offset下标，每次消费数据的时候若是提交offset，那么下次消费就会从提交的offset加一那里开始消费。
好比一个topic中有100条数据，我消费了50条而且提交了，那么此时的kafka服务端记录提交的offset就是49(offset从0开始)，那么下次消费的时候offset就从50开始消费。
解决方案也很简单，改为手动提交便可。
ActiveMQ和RocketMQ你们自行查阅吧。
七、如何保证消息的顺序性？
分析:其实并不是全部的公司都有这种业务需求，可是仍是对这个问题要有所复习。
回答:针对这个问题，经过某种算法，将须要保持前后顺序的消息放到同一个消息队列中(kafka中就是partition,rabbitMq中就是queue)。而后只用一个消费者去消费该队列。
有的人会问:那若是为了吞吐量，有多个消费者去消费怎么办？
这个问题，没有固定回答的套路。好比咱们有一个微博的操做，发微博、写评论、删除微博，这三个异步操做。若是是这样一个业务场景，那只要重试就行。好比你一个消费者先执行了写评论的操做，可是这时候，微博都还没发，写评论必定是失败的，等一段时间。等另外一个消费者，先执行写评论的操做后，再执行，就能够成功。
总之，针对这个问题，个人观点是保证入队有序就行，出队之后的顺序交给消费者本身去保证，没有固定套路。
八、主要消息中间件对比
（1）ActiveMQ
单机吞吐量：万级
topic数量都吞吐量的影响：
时效性：ms级
可用性：高，基于主从架构实现高可用性
消息可靠性：有较低的几率丢失数据
功能支持：MQ领域的功能极其完备
总结：
很是成熟，功能强大，在早些年业内大量的公司以及项目中都有应用
偶尔会有较低几率丢失消息
如今社区以及国内应用都愈来愈少，官方社区如今对ActiveMQ 5.x维护愈来愈少，几个月才发布一个版本
主要是基于解耦和异步来用的，较少在大规模吞吐的场景中使用
（2）RabbitMQ
单机吞吐量：万级
topic数量都吞吐量的影响：
时效性：微秒级，延时低是一大特色。
可用性：高，基于主从架构实现高可用性
消息可靠性：
功能支持：基于erlang开发，因此并发能力很强，性能极其好，延时很低
总结：
erlang语言开发，性能极其好，延时很低；
吞吐量到万级，MQ功能比较完备
开源提供的管理界面很是棒，用起来很好用
社区相对比较活跃，几乎每月都发布几个版本分
在国内一些互联网公司近几年用rabbitmq也比较多一些 可是问题也是显而易见的，RabbitMQ确实吞吐量会低一些，这是由于他作的实现机制比较重。
erlang开发，很难去看懂源码，基本职能依赖于开源社区的快速维护和修复bug。
rabbitmq集群动态扩展会很麻烦，不过这个我以为还好。其实主要是erlang语言自己带来的问题。很难读源码，很难定制和掌控。
（3）RocketMQ
单机吞吐量：十万级
topic数量都吞吐量的影响：topic能够达到几百，几千个的级别，吞吐量会有较小幅度的降低。可支持大量topic是一大优点。
时效性：ms级
可用性：很是高，分布式架构
消息可靠性：通过参数优化配置，消息能够作到0丢失
功能支持：MQ功能较为完善，仍是分布式的，扩展性好
总结：
接口简单易用，能够作到大规模吞吐，性能也很是好，分布式扩展也很方便，社区维护还能够，可靠性和可用性都是ok的，还能够支撑大规模的topic数量，支持复杂MQ业务场景
并且一个很大的优点在于，源码是java，咱们能够本身阅读源码，定制本身公司的MQ，能够掌控
社区活跃度相对较为通常，不过也还能够，文档相对来讲简单一些，而后接口这块不是按照标准JMS规范走的有些系统要迁移须要修改大量代码
阿里巴巴：
https://help.aliyun.com/document_detail/29532.html?spm=a2c4g.11186623.6.542.c87170fb58btRJ
消息队列 RocketMQ 是阿里巴巴集团基于高可用分布式集群技术，自主研发的云正式商用的专业消息中间件，既可为分布式应用系统提供异步解耦和削峰填谷的能力，同时也具有互联网应用所需的海量消息堆积、高吞吐、可靠重试等特性，是阿里巴巴双 11 使用的核心产品。
（4）Kafka
单机吞吐量：十万级，最大的优势，就是吞吐量高。
topic数量都吞吐量的影响：topic从几十个到几百个的时候，吞吐量会大幅度降低。因此在同等机器下，kafka尽可能保证topic数量不要过多。若是要支撑大规模topic，须要增长更多的机器资源
时效性：ms级
可用性：很是高，kafka是分布式的，一个数据多个副本，少数机器宕机，不会丢失数据，不会致使不可用
消息可靠性：通过参数优化配置，消息能够作到0丢失
功能支持：功能较为简单，主要支持简单的MQ功能，在大数据领域的实时计算以及日志采集被大规模使用
总结：
kafka的特色其实很明显，就是仅仅提供较少的核心功能，可是提供超高的吞吐量，ms级的延迟，极高的可用性以及可靠性，并且分布式能够任意扩展
同时kafka最好是支撑较少的topic数量便可，保证其超高吞吐量
kafka惟一的一点劣势是有可能消息重复消费，那么对数据准确性会形成极其轻微的影响，在大数据领域中以及日志采集中，这点轻微影响能够忽略
（5）总结：
通常的业务系统要引入MQ，最先你们都用ActiveMQ，可是如今确实你们用的很少了，没通过大规模吞吐量场景的验证，社区也不是很活跃
后来你们开始用RabbitMQ，可是确实erlang语言阻止了大量的java工程师去深刻研究和掌控他，对公司而言，几乎处于不可控的状态，可是确实人家是开源的，比较稳定的支持，活跃度也高；
不过如今确实愈来愈多的公司，会去用RocketMQ，确实很不错，可是要想好社区万一忽然黄掉的风险
因此中小型公司，技术实力较为通常，技术挑战不是特别高，用RabbitMQ是不错的选择；大型公司，基础架构研发实力较强，用RocketMQ是很好的选择
若是是大数据领域的实时计算、日志采集等场景，用Kafka是业内标准的，绝对没问题，社区活跃度很高，绝对不会黄，况且几乎是全世界这个领域的事实性规范。