一： 为什么使用消息队列？二： 使用消息队列有什么缺点?三： 消息队列如何选型?四： 如何保证消息队列是高可用的？五： 如何保证消息不被重复消费?六.： 如何保证消费的可靠性传输?七：如何保证消息的顺序性？八：消息的匹配九：消息的超时十：消息的保持十一：消息的错误处理十二、消息的吞吐量
一： 为什么使用消息队列？(1)解耦
传统模式:
传统模式的缺点：
系统间耦合性太强，如上图所示，系统A在代码中直接调用系统B和系统C的代码，如果将来D系统接入，系统A还需要修改代码，过于麻烦！
中间件模式:
中间件模式的的优点：将消息写入消息队列，需要消息的系统自己从消息队列中订阅，从而系统A不需要做任何修改。
(2)异步
传统模式:
传统模式的缺点：一些非必要的业务逻辑以同步的方式运行，太耗费时间。
中间件模式:
中间件模式的的优点：将消息写入消息队列，非必要的业务逻辑以异步的方式运行，加快响应速度
(3)削峰
传统模式
传统模式的缺点：并发量大的时候，所有的请求直接怼到数据库，造成数据库连接异常
中间件模式:
中间件模式的的优点：系统A慢慢的按照数据库能处理的并发量，从消息队列中慢慢拉取消息。在生产中，这个短暂的高峰期积压是允许的。
二： 使用消息队列有什么缺点?
分析:一个使用了MQ的项目，如果连这个问题都没有考虑过，就把MQ引进去了，那就给自己的项目带来了风险。我们引入一个技术，要对这个技术的弊端有充分的认识，才能做好预防。要记住，不要给公司挖坑！
回答:回答也很容易，从以下两个个角度来答
系统可用性降低:你想啊，本来其他系统只要运行好好的，那你的系统就是正常的。现在你非要加个消息队列进去，那消息队列挂了，你的系统不是呵呵了。因此，系统可用性降低系统复杂性增加:要多考虑很多方面的问题，比如一致性问题、如何保证消息不被重复消费，如何保证保证消息可靠传输。因此，需要考虑的东西更多，系统复杂性增大。
但是，我们该用还是要用的。
三： 消息队列如何选型?
总的来说，三大原因，语言、潮流、生态。
MQ这种东西，当你的消息量不大的时候，用啥是没多大区别的。特别是在过去20年里，有些阶段你没多少开源的MQ可选，所以最开始ActiveMQ和RabbitMQ还是很火的。
ActiveMQ、RabbitMQ、Kafka/RocketMQ，包括最近很火的pulsar，都非常有自己的特色，但是中间件这条线上，越早出现的，包袱越大，功能可能更多，比如ActiveMQ发展16年了，，，有大几百个功能，，你能想到的所有消息领域的特性，它全都有，所有消息协议 ，都支持，搞的太重了。淘宝最早期的notify，就是借鉴ActiveMQ来的。
京东多年使用大规模的ActiveMQ集群，10年前就有几百台了，然后发现古老的MQ模型，broker太重，量一大就卡（90%用ActiveMQ，但是有一定规模的数据量，这个问题都搞不好搞），然后慢慢发展了自己的JMQ。当年大家消息吞吐量都不大的时候，RabbitMQ就是神器，吞吐高出ActiveMQ几倍。但是慢慢大家发现，真有什么问题，团队没有erlang高手的话，没任何办法。比如说，一天几个亿、几十亿的消息，RabbitMQ一卡主，上下游所有交易订单处理，全都蹦掉了。
这个时候，linkedin搞出来了kafka，天然支持消息堆积。然后很快twitter之类的公司快速跟上，在传输消息量非常大的几个领域，大数据的数据传输，日志和监控数据收集，等领域就支持称霸了。这个几年的代差，让大家不在一个起跑线上。紧接着淘宝尝试用kafka效果不错，但是搞不定scala，然后像从ActiveMQ发展出来了notify一样，，基本上用java把kafka翻译了一遍，有了metaq，，，然后再逐渐出来了
RocketMQ，发展了很多年，跟Kafka有一些小的差异，本质上还是那一套。特别是最近这5-6年，随着整个互联网数据量的进一步增大，kafka/rocketmq在越来越丰富的场景下证明了分布式+支持堆积消息的优越性。大家积累了大量的经验和应用场景，然后发现日常做业务也可以放心大胆用mq处理了。
最后kafka和RocketMQ本身社区活跃，工具体系丰富，发展的很快（ActiveMQ中间尝试6.x版本浪费了很多年，最近两年跟hornetq合并才有新的发展方向。RabbitMQ中间也错失了一些机会。特别是RabbitMQ属于pivotal，spring品牌所在的公司，有个erlang的产品，跟其他的东西相比，蛮奇怪的，也许这也有些原因。）。
总而言之，现在技术发展太快了，越是后起之秀，越能站上前辈的肩膀上，实现弯道超车 。Kafka/RocketMQ，首先是基于JVM和Java，其次就是赶上了数据量爆发的快车道，最后是体系工具非常丰富，所以目前基本上占山为王（时至今日，几乎可以说，rpc和mq是分布式大厦门口最基础的两块砖。）。
Kafka在stream流处理的道路上越走越远，下一波大的技术浪潮也许还能赶上。个人非常看好pulsar，在kafka的基础上，进一步的分离计算和存储（计算存储分离是下一代基础软件的大趋势），国内很多人在负责和参与这个新的MQ项目。
综合上面的材料得出以下两点:
一般的业务系统要引入 MQ，最早大家都用 ActiveMQ，但是现在确实大家用的不多了，没经过大规模吞吐量场景的验证，社区也不是很活跃，所以大家还是算了吧，我个人不推荐用这个了；
后来大家开始用 RabbitMQ，但是确实 erlang 语言阻止了大量的 Java 工程师去深入研究和掌控它，对公司而言，几乎处于不可控的状态，但是确实人家是开源的，比较稳定的支持，活跃度也高；
不过现在确实越来越多的公司会去用 RocketMQ，确实很不错，毕竟是阿里出品，但社区可能有突然黄掉的风险（目前 RocketMQ 已捐给 Apache，但 GitHub 上的活跃度其实不算高）对自己公司技术实力有绝对自信的，推荐用 RocketMQ，否则回去老老实实用 RabbitMQ 吧，人家有活跃的开源社区，绝对不会黄。所以中小型公司，技术实力较为一般，技术挑战不是特别高，用 RabbitMQ 是不错的选择；
大型公司，基础架构研发实力较强，用 RocketMQ 是很好的选择。如果是大数据领域的实时计算、日志采集等场景，用 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的拓补架构图(也是找的，懒得画)
分析:这个问题其实换一种问法就是，如何保证消息队列的幂等性?这个问题可以认为是消息队列领域的基本问题。换句话来说，是在考察你的设计能力，这个问题的回答可以根据具体的业务场景来答，没有固定的答案。
回答:先来说一下为什么会造成重复消费?
其实无论是那种消息队列，造成重复消费原因其实都是类似的。正常情况下，消费者在消费消息时候，消费完毕后，会发送一个确认信息给消息队列，消息队列就知道该消息被消费了，就会将该消息从消息队列中删除。只是不同的消息队列发送的确认信息形式不同,例如RabbitMQ是发送一个ACK确认消息，RocketMQ是返回一个CONSUME_SUCCESS成功标志，kafka实际上有个offset的概念，简单说一下(如果还不懂，出门找一个kafka入门到精通教程),就是每一个消息都有一个offset，kafka消费过消息后，需要提交offset，让消息队列知道自己已经消费过了。那造成重复消费的原因?，就是因为网络传输等等故障，确认信息没有传送到消息队列，导致消息队列不知道自己已经消费过该消息了，再次将该消息分发给其他的消费者。
如何解决?这个问题针对业务场景来答分以下几点
(1)比如，你拿到这个消息做数据库的insert操作。那就容易了，给这个消息做一个唯一主键，那么就算出现重复消费的情况，就会导致主键冲突，避免数据库出现脏数据。
(2)再比如，你拿到这个消息做redis的set的操作，那就容易了，不用解决，因为你无论set几次结果都是一样的，set操作本来就算幂等操作。
(3)如果上面两种情况还不行，上大招。准备一个第三方介质,来做消费记录。以redis为例，给消息分配一个全局id，只要消费过该消息，将
分析:这个问题其实换一种问法就是，如何保证消息队列的幂等性?这个问题可以认为是消息队列领域的基本问题。换句话来说，是在考察你的设计能力，这个问题的回答可以根据具体的业务场景来答，没有固定的答案。
回答:先来说一下为什么会造成重复消费?
其实无论是那种消息队列，造成重复消费原因其实都是类似的。正常情况下，消费者在消费消息时候，消费完毕后，会发送一个确认信息给消息队列，消息队列就知道该消息被消费了，就会将该消息从消息队列中删除。只是不同的消息队列发送的确认信息形式不同,例如RabbitMQ是发送一个ACK确认消息，RocketMQ是返回一个CONSUME_SUCCESS成功标志，kafka实际上有个offset的概念，简单说一下(如果还不懂，出门找一个kafka入门到精通教程),就是每一个消息都有一个offset，kafka消费过消息后，需要提交offset，让消息队列知道自己已经消费过了。那造成重复消费的原因?，就是因为网络传输等等故障，确认信息没有传送到消息队列，导致消息队列不知道自己已经消费过该消息了，再次将该消息分发给其他的消费者。
如何解决?这个问题针对业务场景来答分以下几点
(1)比如，你拿到这个消息做数据库的insert操作。那就容易了，给这个消息做一个唯一主键，那么就算出现重复消费的情况，就会导致主键冲突，避免数据库出现脏数据。
(2)再比如，你拿到这个消息做redis的set的操作，那就容易了，不用解决，因为你无论set几次结果都是一样的，set操作本来就算幂等操作。
(3)如果上面两种情况还不行，上大招。准备一个第三方介质,来做消费记录。以redis为例，给消息分配一个全局id，只要消费过该消息，将
分析:我们在使用消息队列的过程中，应该做到消息不能多消费，也不能少消费。如果无法做到可靠性传输，可能给公司带来千万级别的财产损失。同样的，如果可靠性传输在使用过程中，没有考虑到，这不是给公司挖坑么，你可以拍拍屁股走了，公司损失的钱，谁承担。还是那句话，认真对待每一个项目，不要给公司挖坑。
回答:其实这个可靠性传输，每种MQ都要从三个角度来分析:生产者弄丢数据、消息队列弄丢数据、消费者弄丢数据
RabbitMQ
(1)生产者丢数据
从生产者弄丢数据这个角度来看，RabbitMQ提供transaction和/confirm/i模式来确保生产者不丢消息。
transaction机制就是说，发送消息前，开启事物(channel.txSelect())，然后发送消息，如果发送过程中出现什么异常，事物就会回滚(channel.txRollback())，如果发送成功则提交事物(channel.txCommit())。
然而缺点就是吞吐量下降了。因此，按照博主的经验，生产上用/confirm/i模式的居多。一旦channel进入/confirm/i模式，所有在该信道上面发布的消息都将会被指派一个唯一的ID(从1开始)，一旦消息被投递到所有匹配的队列之后，rabbitMQ就会发送一个Ack给生产者(包含消息的唯一ID)，这就使得生产者知道消息已经正确到达目的队列了.如果rabiitMQ没能处理该消息，则会发送一个Nack消息给你，你可以进行重试操作。处理Ack和Nack的代码如下所示
(2)消息队列丢数据
处理消息队列丢数据的情况，一般是开启持久化磁盘的配置。这个持久化配置可以和/confirm/i机制配合使用，你可以在消息持久化磁盘后，再给生产者发送一个Ack信号。这样，如果消息持久化磁盘之前，rabbitMQ阵亡了，那么生产者收不到Ack信号，生产者会自动重发。
那么如何持久化呢，这里顺便说一下吧，其实也很容易，就下面两步
1、将queue的持久化标识durable设置为true,则代表是一个持久的队列
2、发送消息的时候将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，一旦写入失败，这无限重试
(1)消息队列丢数据
针对消息队列丢数据的情况，无外乎就是，数据还没同步，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开始消费。
解决方案也很简单，改成手动提交即可。
有这样一个需求：当订单状态变化的时候，把订单状态变化的消息发送给所有关心订单变化的系统。
订单会有创建成功、待付款、已支付、已发货的状态，状态之间是单向流动的。
好，现在我们把订单状态变化消息要发送给所有关心订单状态的系统上去，实现方式就是用消息队列。
在这种业务下，我们最想要的是什么？
1.消息的顺序：对于同一笔订单来说，状态的变化都是有严格的先后顺序的。
2.吞吐量：像订单的业务，我们自然希望订单越多越好。订单越多，吞吐量就越大。在这种情况下，我们先看看 RabbitMQ 是怎么做的。
首先，对于发消息，并广播给多个消费者这种情况，RabbitMQ 会为每个消费者建立一个对应的队列。也就是说，如果有 10 个消费者，RabbitMQ 会建立 10 个对应的队列。然后，当一条消息被发出后，RabbitMQ 会把这条消息复制 10 份放到这 10 个队列里。
当 RabbitMQ 把消息放入到对应的队列后，我们紧接着面临的问题就是，我们应该在系统内部启动多少线程去从消息队列中获取消息。
如果只是单线程去获取消息，那自然没有什么好说的。但是多线程情况，可能就会有问题了……
RabbitMQ 有这么个特性，它在官方文档就声明了自己是不保证多线程消费同一个队列的消息，一定保证顺序的。而不保证的原因，是因为多线程时，当一个线程消费消息报错的时候，RabbitMQ 会把消费失败的消息再入队，此时就可能出现乱序的情况。
T0 时刻，队列中有四条消息 A1、B1、B2、A2。其中 A1、A2 表示订单 A 的两个状态：待付款、已付款。
B1、B2 也同理，是订单 B 的待付款、已付款。
到了 T1 时刻，消息 A1 被线程 1 收到，消息 B1 被线程 2 收到。此时，一切都还正常。
到了 T3 时刻，B1 消费出错了，同时呢，由于线程 1 处理速度快，又从消息队列中获取到了 B2。此时，问题开始出现。
到了 T4 时刻，由于 RabbitMQ 线程消费出错，可以把消息重新入队的特性，此时 B1 会被重新放到队列头部。
所以，如果不凑巧，线程 1 获取到了 B1，就出现了乱序情况，B2 状态明明是 B1 的后续状态，却被提前处理了。所以，可以看到了，这个场景用 RabbitMQ，出现了三个问题：
1.为了实现发布订阅功能，从而使用的消息复制，会降低性能并耗费更多资源
2.多个消费者无法严格保证消息顺序
3.大量的订单集中在一个队列，吞吐量受到了限制
那么 Kafka 怎么样呢？Kafka 正好在这三个问题上，表现的要比 RabbitMQ 要好得多。
首先，Kafka 的发布订阅并不会复制消息，因为 Kafka 的发布订阅就是消费者直接去获取被 Kafka 保存在日志文件中的消息就好。无论是多少消费者，他们只需要主动去找到消息在文件中的位置即可。
其次，Kafka 不会出现消费者出错后，把消息重新入队的现象。最后，Kafka 可以对订单进行分区，把不同订单分到多个分区中保存，这样，吞吐量能更好。所以，对于这个需求 Kafka 更合适。
我曾经做过一套营销系统。这套系统中有个非常显著的特点，就是非常复杂非常灵活地匹配规则。
比如，要根据推广内容去匹配不同的方式做宣传。又比如，要根据不同的活动去匹配不同的渠道去做分发。
总之，数不清的匹配规则是这套系统中非常重要的一个特点。
首先，先看看 RabbitMQ 的，你会发现 RabbitMQ 是允许在消息中添加 routing_key 或者自定义消息头，然后通过一些特殊的 Exchange，很简单的就实现了消息匹配分发。开发几乎不用成本。
而 Kafka 呢？如果你要实现消息匹配，开发成本高多了。
首先，通过简单的配置去自动匹配和分发到合适的消费者端这件事是不可能的。
其次，消费者端必须先把所有消息不管需要不需要，都取出来。然后，再根据业务需求，自己去实现各种精准和模糊匹配。可能因为过度的复杂性，还要引入规则引擎
这个场景下 RabbitMQ 扳回一分。
九：消息的超时在电商业务里，有个需求：下单之后，如果用户在 15 分钟内未支付，则自动取消订单。
你可能奇怪，这种怎么也会用到消息队列的？
我来先简单解释一下，在单一服务的系统，可以起个定时任务就搞定了。
但是，在 SOA 或者微服务架构下，这样做就不行了。因为很多个服务都关心是否支付这件事，如果每种服务，都自己实现一套定时任务的逻辑，既重复，又难以维护。
在这种情况下，我们往往会做一层抽象：把要执行的任务封装成消息。当时间到了，直接扔到消息队列里，消息的订阅者们获取到消息后，直接执行即可。
希望把消息延迟一定时间再处理的，被称为延迟队列。
对于订单取消的这种业务，我们就会在创建订单的时候，同时扔一个包含了执行任务信息的消息到延迟队列，指定15分钟后，让订阅这个队列的各个消费者，可以收到这个消息。随后，各个消费者所在的系统就可以去执行相关的扫描订单的任务了。
RabbitMQ 和 Kafka 消息队列如何选？
先看下 RabbitMQ 的。RabbitMQ 的消息自带手表，消息中有个 TTL 字段，可以设置消息在 RabbitMQ 中的存放的时间，超时了会被移送到一个叫死信队列的地方。
所以，延迟队列 RabbitMQ 最简单的实现方式就是设置 TTL，然后一个消费者去监听死信队列。当消息超时了，监听死信队列的消费者就收到消息了。
不过，这样做有个大问题：假设，我们先往队列放入一条过期时间是 10 秒的 A 消息，再放入一条过期时间是 5 秒的 B 消息。 那么问题来了，B 消息会先于 A 消息进入死信队列吗？
答案是否定的。B 消息会优先遵守队列的先进先出规则，在 A 消息过期后，和其一起进入死信队列被消费者消费。
在 RabbitMQ 的 3.5.8 版本以后，官方推荐的 rabbitmq delayed message exchange 插件可以解决这个问题。
用了这个插件，我们在发送消息的时候，把消息发往一个特殊的 Exchange。
-同时，在消息头里指定要延迟的时间。收到消息的 Exchange 并不会立即把消息放到队列里，而是在消息延迟时间到达后，才会把消息放入。
再看下 Kafka 的：
Kafka 要实现延迟队列就很麻烦了。
你先需要把消息先放入一个临时的 topic。然后得自己开发一个做中转的消费者。让这个中间的消费者先去把消息从这个临时的 topic 取出来。取出来，这消息还不能马上处理啊，因为没到时间呢。也没法保存在自己的内存里，怕崩溃了，消息没了。所以，就得把没有到时间的消息存入到数据库里。
-存入数据库中的消息需要在时间到了之后再放入到 Kafka 里，以便真正的消费者去执行真正的业务逻辑。……
想想就已经头大了，这都快搞成调度平台了。
再高级点，还要用时间轮算法才能更好更准确。
这次，RabbitMQ 上那一条条戴手表的消息，才是最好的选择。
在微服务里，事件溯源模式是经常用到的。如果想用消息队列实现，一般是把事件当成消息，依次发送到消息队列中。
事件溯源有个最经典的场景，就是事件的重放。简单来讲就是把系统中某段时间发生的事件依次取出来再处理。而且，根据业务场景不同，这些事件重放很可能不是一次，更可能是重复 N 次。
假设，我们现在需要一批在线事件重放，去排查一些问题。
RabbitMQ 此时就真的不行了，因为消息被人取出来就被删除了。
想再次被重复消费？对不起。
而 Kafka 呢，消息会被持久化一个专门的日志文件里。不会因为被消费了就被删除。
所以，对消息不离不弃的 Kafka 相对用过就抛的 RabbitMQ，请选择 Kafka。
很多时候，在做记录数据相关业务的时候，Kafka 一般是不二选择。不过，有时候在记录数据吞吐量不大时，我自己倒是更喜欢用 RabbitMQ。
原因就是 Kafka 有一个我很不喜欢的设计原则：
当单个分区中的消息一旦出现消费失败，就只能停止而不是跳过这条失败的消息继续消费后面的消息。即不允许消息空洞。
只要消息出现失败，不管是 Kafka 自身消息格式的损坏，还是消费者处理出现异常，是不允许跳过消费失败的消息继续往后消费的。
所以，在数据统计不要求十分精确的场景下选了 Kafka，一旦出现了消息消费问题，就会发生项目不可用的情况。这真是徒增烦恼。
而 RabbitMQ 呢，它由于会在消息出问题或者消费错误的时候，可以重新入队或者移动消息到死信队列，继续消费后面的，会省心很多。
坏消息就像群众中的坏蛋那样，Kafka 处理这种坏蛋太过残暴，非得把坏蛋揪出来不行。相对来说，RabbitMQ 就温柔多了，群众是群众，坏蛋是坏蛋，分开处理嘛。
Kafka 是每秒几十万条消息吞吐，而 RabbitMQ 的吞吐量是每秒几万条消息。
其实，在一家公司内部，有必须用到 Kafka 那么大吞吐量的项目真的很少。大部分项目，像 RabbitMQ 那样每秒几万的消息吞吐，已经非常够了。
在一些没那么大吞吐量的项目中引入 Kafka，我觉得就不如引入 RabbitMQ。
为什么呢？
因为 Kafka 为了更好的吞吐量，很大程度上增加了自己的复杂度。而这些复杂度对项目来说，就是麻烦，主要体现在两个方面：
1、配置复杂、维护复杂Kafka 的参数配置相对 RabbitMQ 是很复杂的。比如：磁盘管理相关参数，集群管理相关参数，ZooKeeper 交互相关参数，Topic 级别相关参数等，都需要一些思考和调优。
另外，Kafka 本身集群和参与管理集群的 ZooKeeper，这就带来了更多的维护成本。Kafka 要用好，你要考虑 JVM，消息持久化，集群本身交互，以及 ZooKeeper 本身和它与 Kafka 之间的可靠和效率。
2、用好，用对存在门槛Kafka 的 Producer 和 Consumer 本身要用好用对也存在很高的门槛。
比如，Producer 消息可靠性保障、幂等性、事务消息等，都需要对 KafkaProducer 有深入的了解。
而 Consumer 更不用说了，光是一个日志偏移管理就让一大堆人掉了不少头发。
相对来说，RabbitMQ 就简单得多。你可能都不用配置什么，直接启动起来就能很稳定可靠地使用了。就算配置，也是寥寥几个参数设置即可。
