kafka架构原理最全解释

https://zhuanlan.zhihu.com/p/76073581

1. 什么是 Kafka?

答：Kafka是一个发布 - 订阅的消息队列中间件。这个消息传递应用程序是用“scala”编码的。 kafka 支持的协议是防AMQP协议，支持集群，负载均衡和动态扩容（zk）, 不支持事务；

它有这么三个比较关键的能力：

发布订阅，可以当做消息队列用
记录的容错持久化
流处理

优点是： 高吞吐，低延时，可扩展

2. 使用消息队列的好处

1. 解耦

允许独立的修改或者扩展两边的处理过程，只要确保其遵循同样的约束接口。

2. 可恢复性

系统的一部分组件失效时，不会影响整个系统。即使部分处理消息的线程挂掉，消息加入队列，也能在系统恢复后被处理。

3. 缓冲

用于解决生产者和消费者速度不一致的情况。

4. 灵活性和峰值处理

在流量激增的情况下不会导致系统奔溃

5. 异步处理

用户收到消息不想立即处理，需要的时候再进行处理。

3. 消费队列模式

1. 点对点

只有一个消费者 flume

2. 发布订阅

只要不删消息都在

队列主动推送：缺点推送的速度统一，但是每一个订阅者的处理速度不一

消费者主动拉取的模式：缺点需要消费者进行长轮询看有没有新消息，浪费资源

kafka 是主动拉取模式，消费者的消费速度可以由自己决

被动拉取的模式， 维护一个用户列表，消息来到，通知消费者，消费队列的两端是可以不同时在线，但是被动通知还需实时监测消费者是否在线

4. Kafka中有哪几个组件?

主题：Kafka主题是一堆或一组消息。

生产者：在Kafka，生产者发布通信以及向Kafka主题发布消息。

消费者：Kafka消费者订阅了一个主题，并且还从主题中读取和处理消息。

经纪人：在管理主题中的消息存储时，我们使用Kafka Brokers。

zookeeper :

5. 不同组件在kafka中的作用

image.png

1. zookeeper 帮助kafka 维护集群 ，存储 topic 信息， topic 分区的 leader ,follow 位置 等信息。消费者会在zookeeper中存储消费的偏移量。0.9 之前。0.9后将偏移量保存在kafka集群topic,存在磁盘。默认存7天。

2. topic 主题会存在 分区 和 副本数， 分区存在 leader 和 follower

分区的好处，提高读写的并行度，提高负载。 副本的作用，用于容灾处理

3. 同一个消费者组里的消费者同一时刻不能消费同一个topic的同一个分区。

消费者组，提高消费数据的能力。消费者组里的消费者个数和分区一致是最好。消费者数不要超过分区数。

消费者组分配的策略问题。

4. 生产者将数据交付分区，存在策略问题。

kafka中的副本数不能超过 可用broker，分区数可以超过。

6. Kafka 为什么那么快？

1. 页缓存
   Kafka并不太依赖JVM内存大小，而是主要利用Page Cache，如果使用应用层缓存（JVM堆内存），会增加GC负担，增加停顿时间和延迟，创建对象的开销也会比较高。

读取操作可以直接在Page Cache上进行，如果消费和生产速度相当，甚至不需要通过物理磁盘直接交换数据，这是Kafka高吞吐量的一个重要原因。

这么做还有一个优势，如果Kafka重启，JVM内的Cache会失效，Page Cache依然可用。

2. 零拷贝
   Kafka中存在大量的网络数据持久化到磁盘（Producer到Broker）和磁盘文件通过网络发送（Broker到Consumer）的过程。这一过程的性能直接影响Kafka的整体吞吐量。

传统四次拷贝：首先通过系统调用将文件数据读入到内核态Buffer（DMA拷贝），然后应用程序将内存态Buffer数据读入到用户态Buffer（CPU拷贝），接着用户程序通过Socket发送数据时将用户态Buffer数据拷贝到内核态Buffer（CPU拷贝），最后通过DMA拷贝将数据拷贝到NIC Buffer。伴随四次切换。

sendfile和transferTo实现零拷贝
Linux 2.4+内核通过sendfile系统调用，提供了零拷贝。数据通过DMA拷贝到内核态Buffer后，直接通过DMA拷贝到NIC Buffer，无需CPU拷贝。这也是零拷贝这一说法的来源。除了减少数据拷贝外，因为整个读文件-网络发送由一个sendfile调用完成，整个过程只有两次上下文切换，因此大大提高了性能。

Java NIO的FileChannel的transferTo和transferFrom方法实现零拷贝。

3. 磁盘的顺序写入

即使是普通的机械磁盘，顺序访问速率也接近了内存的随机访问速率。

Kafka的每条消息都是append的，不会从中间写入和删除消息，保证了磁盘的顺序访问。

即使是顺序读写，过于频繁的大量小IO操作一样会造成磁盘的瓶颈，此时又变成了随机读写。Kafka的策略是把消息集合在一起，批量发送，尽可能减少对磁盘的访问。所以，Kafka的Topic和Partition数量不宜过多。

超过64个Topic/Partition以后，Kafka性能会急剧下降。

RocketMQ存储模型与Kafka有些差异，RocketMQ会把所有的数据存放在相同的日志文件，所以单机可以支持非常多的队列。

4. 全异步

Kafka基本上是没有阻塞操作的，调用发送方法会立即返回，等待buffer满了以后交给轮询线程，发送和接收消息，复制数据也是都是通过NetworkClient封装的poll方式。

5. 批量操作

结合磁盘顺序写入，批量无疑是非常有必要（如果用的时候每发送一条消息都调用future.get等待，性能至少下降2个数量级）。写入的时候放到RecordAccumulator进行聚合，批量压缩，还有批量刷盘等...

6. reactor 网络模型
   Kafka 的网络层使用 reactor 的线程模型，单个 acceptor 线程负责处理所有客户端的连接，建立连接后将 socket 的轮询分发给多个 processor 线程处理读写请求，processor 只负责数据的接收和发送，其后还有多个 handler 线程进行具体的逻辑操作，通过这样的异步线程模型，kafka 能够与成千上万的客户端交互而毫无压力

7. kafka 的工作流程

1 写入方式
producer采用推（push）模式将消息发布到broker，每条消息都被追加（append）到分区（patition）中，属于顺序写磁盘（顺序写磁盘效率比随机写内存要高，保障kafka吞吐率）。

2 分区（Partition）
Kafka集群有多个消息代理服务器（broker-server）组成，发布到Kafka集群的每条消息都有一个类别，用主题（topic）来表示。

3. 偏移量
   集群为每个主题维护了分布式的分区（partition）日志文件，物理意义上可以把主题（topic）看作进行了分区的日志文件（partition log）。主题的每个分区都是一个有序的、不可变的记录序列，新的消息会不断追加到日志中。分区中的每条消息都会按照时间顺序分配到一个单调递增的顺序编号，叫做偏移量（offset），这个偏移量能够唯一地定位当前分区中的每一条消息。

每个Partition中的消息都是有序的，生产的消息被不断追加到Partition log上，其中的每一个消息都被赋予了一个唯一的offset值。

消费者 offset 是按照 组 + 分区 + topic 来进行维护

发布到Kafka主题的每条消息包括键值和时间戳。消息到达服务器端的指定分区后，都会分配到一个自增的偏移量。原始的消息内容和分配的偏移量以及其他一些元数据信息最后都会存储到分区日志文件中。

4. 写入流程

image.png

1）producer先从zookeeper的 “/brokers/…/state”节点找到该partition的leader
2）producer将消息发送给该leader
3）leader将消息写入本地log
4）followers从leader pull消息，写入本地log后向leader发送ACK
5）leader收到所有ISR中的replication的ACK后，增加HW（high watermark，最后commit 的offset）并向producer发送ACK

5. 存储策略
   无论消息是否被消费，kafka都会保留所有消息。有两种策略可以删除旧数据：
   1）基于时间：log.retention.hours=168
   2）基于大小：log.retention.bytes=1073741824

6. 消费策略

Kafka采用拉取模型，由消费者自己记录消费状态，每个消费者互相独立地顺序读取每个分区的消息。如下图所示，有两个消费者（不同消费者组）拉取同一个主题的消息，消费者A的消费进度是3，消费者B的消费进度是6。消费者拉取的最大上限通过最高水位（watermark）控制，生产者最新写入的消息如果还没有达到备份数量，对消费者是不可见的。这种由消费者控制偏移量的优点是：消费者可以按照任意的顺序消费消息。比如，消费者可以重置到旧的偏移量，重新处理之前已经消费过的消息；或者直接跳到最近的位置，从当前的时刻开始消费。

8. 生产者策略?

1. 分区：默认是 RR 的轮询分区划分规则， 若指定了Key 则将key的hash值 % 分区号进行分区

2. kafka数据的可靠性： 分区必须确认收到，同时副本备份成功。 ack

半数以上follower完成备份 发送 ACK, 问题是选举新的leader ,容忍 n 台故障，需要 2n + 1 个副本

全部完成， 问题是延迟长， Kafka 选择这种，但是问题是 存在一个慢 ，或者挂掉，

3. ISR 代表同步副本，leader 从 ISR 中选新 leader, 通信时间 ，在延迟时间内去掉

kafka 中维护 ISR 的队列

当leader 接受到消息后，通知 ISR 中的follow 完成备份

4. acks 0 收到， 1 leader 完成 -1 leader,follower所有follow完成，（重复数据）

产生同步数据 ，follower 备份完成后， 这是leader 挂掉， producer 任务没收到，向follewer备份选举后的重复发送数据

一致性： follower还没同步完成，同步一半 leader 挂了，选举后作为leader 后原leader 活了，导致数据不一致

消费数据一致性：Leo: 每一个分区副本的最大 offset ，设置一个 HW 指的是高水位，所有分区leo的最小位置,HW之前的数据才对消费者可见

存储数据一致性： 重新选leader 给所有分区发生消息，直接截取数据到HW.

5. exactly-once : ack 为0 at-less-most

幂等性 + 至少一次 为精准一次

使用幂等性，在kafka 的 broker 消除数据的重复， kafka使用幂等性，默认 ack 为-1

首先给每一个生产者 添加一个 id , 给每一个消息 添加一个序列号， 如果同一个 生产者， 同一个消息序列号， 发往同一个分区，如果已经接受过，就进行去重。

但是生产者挂了重启，那么它的id 号也就变了，也就不能保证精准 一致性

9. 消费者策略?

1. 分区 ， RR 轮询，将当前消费者组不同的主题，当做一个整体，经轮询。好处，消费者组里面的消费最多差一个。

保证消费者组里面消费的topic 是一样的。 Range 是按照单个主题进行划分，将不同的topic 不当做一个整体进行考虑。

触发时在消费者组里面消费者个数变化时会触发分区，重新设置分配分配策略。

Range 分区不会把主题看做一个整体进行划分

假设 有两个主题， T1(0,1,2), T2(0,1,2), 两个消费者组 （A，B） (C)

A 消费者 订阅 T1 , B 订阅 T1， T2 ，C 订阅了 T1

RR : 如果采用的RR 发现 A,B 消费者共用同一个组， 则会把 A,B 订阅的topic 当做一个整体进行考虑。

A,B 进行轮询的分区有：　T1 0 T1 1 T1 2 T2 0 T2 1 T2 3

Range : 按主题划分，先考虑谁订阅了这个主题，然后再进行划分

2. offset

消费者组 + 主题 + 分区 决定 offset, 消费者连接
Kafka 可以顺序写磁盘， 零拷贝技术

9 是什么确保了Kafka中服务器的负载平衡？

答：使用消费者策略和生产者策略保证负载均衡

10. 副本和ISR扮演什么角色？

答：基本上，复制日志的节点列表就是副本。特别是对于特定的分区。但是，无论他们是否扮演领导者的角色，他们都是如此。
此外，ISR指的是同步副本。在定义ISR时，它是一组与领导者同步的消息副本。

11. 有哪些情形会造成重复消费？

消费者消费后没有commit offset(程序崩溃/强行kill/消费耗时/自动提交偏移情况下unscrible)

https://www.cnblogs.com/wangzhuxing/p/10124308.html

（1）生产者发送重复解决方案

1、启动kafka的幂等性
　　要启动kafka的幂等性，无需修改代码，默认为关闭，需要修改配置文件:enable.idempotence=true 同时要求 ack=all 且 retries>1。

幂等原理：每个producer有一个producer id，服务端会通过这个id关联记录每个producer的状态，每个producer的每条消息会带上一个递增的sequence，服务端会记录每个producer对应的当前最大sequence，producerId + sequence ，如果新的消息带上的sequence不大于当前的最大sequence就拒绝这条消息，如果消息落盘会同时更新最大sequence，这个时候重发的消息会被服务端拒掉从而避免消息重复。该配置同样应用于kafka事务中。

2、ack=0，不重试。

可能会丢消息，适用于吞吐量指标重要性高于数据丢失，例如：日志收集。

（2）消费者重复消费解决方案

1、取消自动自动提交
每次消费完或者程序退出时手动提交。这可能也没法保证一条重复。

2、下游做幂等
一般的解决方案是让下游做幂等或者尽量每消费一条消息都记录offset，对于少数严格的场景可能需要把offset或唯一ID,例如订单ID和下游状态更新放在同一个数据库里面做事务来保证精确的一次更新或者在下游数据表里面同时记录消费offset，然后更新下游数据的时候用消费位点做乐观锁拒绝掉旧位点的数据更新。

flink 使用 upset 来保证数据的幂等性，每一个数据都有一个唯一的id, 不存在插入，存在更新

https://www.cnblogs.com/bigshark/p/11210876.html

https://www.cnblogs.com/kevingrace/p/9443270.html

https://blog.csdn.net/zhangxm_qz/article/details/87636094?utm_medium=distribute.pc_relevant_t0.none-task-blog-BlogCommendFromMachineLearnPai2-1.nonecase&depth_1-utm_source=distribute.pc_relevant_t0.none-task-blog-BlogCommendFromMachineLearnPai2-1.nonecase

https://blog.csdn.net/CoderBoom/article/details/84845197

12. follower 故障 和 leader 故障的情况下可靠性保证？

1. follower故障会被踢出ISR,待follower恢复后，follower会读取本地磁盘记录的上次HW, 并将log高于HW的截去，从HW开始向leader同步，等待follower的LEO大于partition的HW,可以重新加入ISR
2. leader 故障，会从ISR中选出新的leader,为保证多副本间数据的一致性，其余的follower将log高于HW部分截去，从新的leader开始进行同步；

13. exactly once 语义

at least once + 幂等性 = exactly once

12. 在生产者中，何时发生QueueFullException？

答：每当Kafka生产者试图以代理的身份在当时无法处理的速度发送消息时，通常都会发生QueueFullException。但是，为了协作处理增加的负载，用户需要添加足够的代理，因为生产者不会阻止。

15. 在Kafka集群中保留期的目的是什么？

答：保留期限保留了Kafka群集中的所有已发布记录。它不会检查它们是否已被消耗。此外，可以通过使用保留期的配置设置来丢弃记录。而且，它可以释放一些空间。

16. 解释Kafka可以接收的消息最大为多少？

答：Kafka可以接收的最大消息大小约为1000000字节。
问题24：传统的消息传递方法有哪些类型？
答：基本上，传统的消息传递方法有两种，如：

排队：这是一种消费者池可以从服务器读取消息并且每条消息转到其中一个消息的方法。
发布-订阅：在发布-订阅中，消息被广播给所有消费者。

17. ISR在Kafka环境中代表什么？

答：ISR指的是同步副本。这些通常被分类为一组消息副本，它们被同步为领导者。

18. 什么是Kafka中的地域复制？

答：对于我们的集群，Kafka MirrorMaker提供地理复制。基本上，消息是通过MirrorMaker跨多个数据中心或云区域复制的。因此，它可以在主动/被动场景中用于备份和恢复；也可以将数据放在离用户更近的位置，或者支持数据位置要求。

19. 解释多租户是什么？

答：我们可以轻松地将Kafka部署为多租户解决方案。但是，通过配置主题可以生成或使用数据，可以启用多租户。此外，它还为配额提供操作支持。

20. Kafka中的数据日志是什么？

答：我们知道，在Kafka中，消息会保留相当长的时间。此外，消费者还可以根据自己的方便进行阅读。尽管如此，有一种可能的情况是，如果将Kafka配置为将消息保留24小时，并且消费者可能停机超过24小时，则消费者可能会丢失这些消息。但是，我们仍然可以从上次已知的偏移中读取这些消息，但仅限于消费者的部分停机时间仅为60分钟的情况。此外，关于消费者从一个话题中读到什么，Kafka不会保持状态。

21. Apache Kafka的缺陷

答：Kafka的局限性是：

没有完整的监控工具集
消息调整的问题
不支持通配符主题选择
速度问题

22. 什么是kafka 消费者重平衡？会造成什么影响？

重平衡本质上是一种协议，规定了 消费者组下的所有消费者，按照什么策略消费 Topic

就是 给消费组 中的每一个消费者分配消费 任务的过程。

重平衡的发生在启动一个消费者组前，但是在某些情况下，会正在运行消费的时，再次发生，可能会导致整个集群的暂时性的瘫痪，影响kafka的高可用。

23. 消费者重平衡的发生时机？

1. 订阅主题数发生变化，这种一般发生在业务改变，数据一定变化

2. 主题的分区发生变化， 启动集群前设置分区数， 之后调节，也是人为调节，可以在半夜

3. 消费端消费组成员的变化， 这个原因产生较大影响，消费者处理消息超时，Kafka集群配置的 max.poll.interval.ms 的值，那么该消费者将会自动离组. 心跳超时，如果消费者在指定的session.timeout.ms时间内没有汇报心跳，
   那么Kafka就会认为该消费已经dead了

24. Kafka 的 副本备份策略是什么？

kafka 采用的是同步和异步共同优点的备份策略，即将leader 的所有 follower 进行同步完毕才返回，ack. 只不过这个全部的副本是指的是 在 ISR 队列中的副本。

ISR 队列，是指 follower 副本存活且和 zookeeper 保持连接，同时其响应时间 较快。不满足条件的会被踢出去，满足的会被加入。

HW 高水位，表明 所有副本都同步到的 offset ，所有分区的最小offset ,那么 leader 也向 消费者提供的 HW.

LEO 每一个分区上的最新(大) offset

kafka采取同步和异步的共同优点，所以使用ISR的方法。把Follow中同步慢的节点从ISR中进行T除，从而保证了复制数据的速度。如果leader副本宕机，那么从ISR中选举出来新的leader副本。因为follow副本中都有记录HW。这样也会减少数据的丢失。Follow副本能够从leader中批量的读取数据并批量写入，从而减少了I/0的开销。

25. kafka 处理请求方案？

kafka 处理请求 类似于 Reactor 模式。

网络线程负责接受 请求， 然后将请求放入共享的请求队列中。

broker 有个 IO线程池， 负责从共享队列中取出请求， 执行真正的处理， 如果是 produce ,将消息写入底层磁盘的日志中， 如果是 fetch ，则从磁盘读取消息。

当 IO线程 处理完请求，将生成的响应 发送到 网络 线程池的响应队列中

请求队列是所有网络线程共享的，而响应队列是每个网络线程专属的

26. kafka controller 的作用？什么是脑裂怎么解决？

早期的版本并没有采用 kafka Controller 对分区和副本进行管理，而是依赖于 zookeeper， 每一个 broker 都会在 zookeeper 上为分区和副本注册大量的监听器。这种严重依赖于zookeeper 会有脑裂和 羊群效应。

只有kafka 的 controller 监控 zookeeper , 其他的 node 再和 controller 通信，减少 zookeeper的 压力。

什么是脑裂？
kafka中只有一个控制器controller 负责分区的leader选举，同步broker的新增或删除消息，但有时由于网络问题，可能同时有两个broker认为自己是controller，这时候其他的broker就会发生脑裂，不知道该听从谁的。

如何解决？controller epoch
每当新的controller产生的时候就会在zk中生成一个全新的、数值更大的controller epoch的标识，并同步给其他的broker进行保存，这样当第二个controller发送指令时，其他的broker就会自动忽略。

27. kafka controller 的竞选策略？

在任意时刻，集群中有且仅有一个控制器。

每个broker启动的时候会去尝试去读取zookeeper 中/controller节点的brokerid的值，如果读取到brokerid的值不为-1，则表示已经有其它broker节点成功竞选为控制器，所以当前broker就会放弃竞选；如果Zookeeper中不存在/controller这个节点，或者这个节点中的数据异常，那么就会尝试去创建/controller这个节点，当前broker去创建节点的时候，也有可能其他broker同时去尝试创建这个节点，只有创建成功的那个broker才会成为控制器，而创建失败的broker则表示竞选失败。每个broker都会在内存中保存当前控制器的brokerid值，这个值可以标识为activeControllerId。

28. 生产者幂等性和事务是什么？

目的： 进行retry重试时，只会生成一个消息。

为了实现Producer的幂等性，Kafka引入了Producer ID（即PID）和Sequence Number。

PID。每个新的Producer在初始化的时候会被分配一个唯一的PID，这个PID对用户是不可见的。

Sequence Numbler。（对于每个PID，该Producer发送数据的每个<Topic, Partition>都对应一个从0开始单调递增的Sequence Number。不是offset

实现原理： broker 在缓存中保存 序列号， 对于接受的每一条消息，如果序列号 比 缓存中的大 1 则接受，否则丢弃。但是者只能保证单个生产者对分区的 exactly once 语义。

，kafka事务属性是指一系列的生产者生产消息和消费者提交偏移量的操作在一个事务，或者说是是一个原子操作），同时成功或者失败。

在事务属性之前先引入了生产者幂等性，它的作用为：

生产者多次发送消息可以封装成一个原子操作，要么都成功，要么失败
consumer-transform-producer模式下，因为消费者提交偏移量出现问题，导致在重复消费消息时，生产者重复生产消息。需要将这个模式下消费者提交偏移量操作和生成者一系列生成消息的操作封装成一个原子操作。

事务属性实现前提是幂等性，即在配置事务属性transaction id时，必须还得配置幂等性；但是幂等性是可以独立使用的，不需要依赖事务属性。

29. 什么是kafka 消费者组？

消费者组是 kafka 提供的可以扩展且具有容错性的消费者机制。 一个分区，只能被消费者组中的一个消费者进行消费。

当消费者数量多于分区数量时，多于的消费者空闲。

当消费者数量少于分区数量时，一个消费者可能订阅多个分区。

发挥 consumer 最大的效果就是，consumer 数和topic 下的 partitions 数相等。

30. Kafka中是怎么体现消息顺序性的？

kafka每个partition中的消息在写入时都是有序的，消费时，每个partition只能被每一个group中的一个消费者消费，保证了消费时也是有序的。
整个topic不保证有序。如果为了保证topic整个有序，那么将partition调整为1.

31. Kafka生产者客户端中使用了几个线程来处理？分别是什么？

2个，主线程和Sender线程。主线程负责创建消息，然后通过分区器、序列化器、拦截器作用之后缓存到累加器RecordAccumulator中。Sender线程负责将RecordAccumulator中消息发送到kafka中.

32. 消费者提交消费位移时提交的是当前消费到的最新消息的offset还是offset+1?

offset+1

34. 有哪些情形会造成重复消费？

消费者消费后没有commit offset(程序崩溃/强行kill/消费耗时/自动提交偏移情况下unscrible)

35. KafkaConsumer是非线程安全的，那么怎么样实现多线程消费？

1.在每个线程中新建一个KafkaConsumer

2.单线程创建KafkaConsumer，多个处理线程处理消息（难点在于是否要考虑消息顺序性，offset的提交方式）

39. Kafka 如何保证数据的顺序性？

kafka：一个topic，一个partition，一个consumer，内部多线程.

kafka写到一个partition中的数据一定是有数据的。

解决办法： 一个topic，一个partition，一个consumer，内部单线程消费，写N个内存queue，然后N个线程分别消费一个内存queue即可，既消费者不要使用多线程进行处理。或者你想多线程进行处理，你可以建立一个内存队列，通过hash进任务id相同分到一个内存队列，每一个内存队列对应一个线程。

40. 常见MQ 的区别？

ActiveMQ ：最早大家都用ActiveMQ，但是现在确实大家用的不多了，没经过大规模吞吐量场景的验证，社区也不是很活跃，单机吞吐量，万级，吞吐量比RocketMQ和Kafka要低了一个数量级，响应为ms级别，有较低的概率丢失数据。

RabbitMQ ：单机吞吐率万级，吞吐量比RocketMQ和Kafka要低了一个数量级，但是适合于中小型企业，因为自带了友好的监控和维护界面，社区相对比较活跃，几乎每个月都发布几个版本分，在国内一些互联网公司近几年用rabbitmq也比较多一些，但是问题也是显而易见的，RabbitMQ确实吞吐量会低一些，这是因为他做的实现机制比较重，同时语言在国内很少有人会。

RocketMQ ：单机吞吐量10万级，RocketMQ也是可以支撑高吞吐的一种MQ，topic可以达到几百，几千个的级别，吞吐量会有较小幅度的下降，这是RocketMQ的一大优势，在同等机器下，可以支撑大量的topic，可用性非常高，分布式架构，在阿里大规模应用过，有阿里品牌保障，日处理消息上百亿之多，可以做到大规模吞吐，性能也非常好，分布式扩展也很方便，源码是JAVA.

Kafka : 单机吞吐量10万级别，这是kafka最大的优点，就是吞吐量高。一般配合大数据类的系统来进行实时数据计算、日志采集等场景.topic从几十个到几百个的时候，吞吐量会大幅度下降
所以在同等机器下，kafka尽量保证topic数量不要过多。如果要支撑大规模topic，需要增加更多的机器资源,可用性非常高，kafka是分布式的，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用。