Kafka

定位

队列较多、消息堆积时性能稳定

单机支持最高5万个队列，Load不会发生明显变化

1、在高吞吐、低延迟、高可用上有非常好的表现；消息堆积时，性能也很好。<br>2、api、系统设计都更加适在业务处理的场景。<br>3、支持多种消费方式。<br>4、支持broker消息过滤。<br>5、支持事务。<br>6、提供消息顺序消费能力；consumer可以水平扩展，消费能力很强。<br>7、集群规模在50台左右，单日处理消息上百亿；经历过大数据量的考验，比较稳定可靠。

1、相比于kafka，使用者较少，生态不够完善。消息堆积、吞吐率上也有所不如。<br>2、不支持主从自动切换，master失效后，消费者需要一定的时间才能感知。<br>3、客户端只支持Java

定时消息、Broker消息过滤、分布式事务消息、

定位

队列/分区多时性能不稳定，明显下降。<br>消息堆积时性能稳定

单机超过64个队列/分区，Load会发生明显的飙高现象，队列越多，load越高，发送消息响应时间变长

生态：Apache Kafka、Kafka Streams、KSQL 和 Kafka Connect

成熟度，支持多语言，百万级TPS

1、在高吞吐、低延迟、高可用、集群热扩展、集群容错上有非常好的表现；<br>2、producer端提供缓存、压缩功能，可节省性能，提高效率。<br>3、提供顺序消费能力<br>4、提供多种客户端语言<br>5、生态完善，在大数据处理方面有大量配套的设施。

Kafka单机超过64个队列/分区，Load会发生明显的飙高现象，队列越多，load越高，发送消息响应时间变长使用短轮询方式，实时性取决于轮询间隔时间；消费失败不支持重试；支持消息顺序，但是一台代理宕机后，就会产生消息乱序；社区更新较慢；

1、消费集群数目受到分区数目的限制。<br>2、单机topic多时，性能会明显降低。<br>3、不支持事务

顺序写日志文件

零拷贝

页缓存

节点路径：

zookeeper管理Broker元数据

Controller在zookeeper注册watcher

创建一条记录，记录中一个要指定对应的 Topic 和 Value，Key 和 Partition 可选。 <br>先序列化，然后按照 Topic 和 Partition，放进对应的发送队列中。Kafka Produce 都是批量请求，会积攒一批，然后一起发送，不是调 send() 就立刻进行网络发包。<br>如果 Partition 没填，那么情况会是这样的：<br>• Key 有填。按照 Key 进行哈希，相同 Key 去一个 Partition。（如果扩展了 Partition 的数量那么就不能保证了）<br>• Key 没填。Round-Robin 来选 Partition。<br>这些要发往同一个 Partition 的请求按照配置，攒一波，然后由一个单独的线程一次性发过去。<br><br><br>

当存在多副本的情况下，会尽量把多个副本，分配到不同的 Broker 上。<br>Kafka 会为 Partition 选出一个 Leader，之后所有该 Partition 的请求，实际操作的都是 Leader，然后再同步到其他的 Follower。<br>当一个 Broker 歇菜后，所有 Leader 在该 Broker 上的 Partition 都会重新选举，选出一个 Leader。（这里不像分布式文件存储系统那样会自动进行复制保持副本数）<br>然后这里就涉及两个细节：<br>• 怎么分配 Partition<br>• 怎么选 Leader<br><br>关于 Partition 的分配，还有 Leader 的选举，总得有个执行者。在 Kafka 中，这个执行者就叫 Controller。<br>Kafka 使用 ZK 在 Broker 中选出一个 Controller，用于 Partition 分配和 Leader 选举。<br>Partition 的分配：<br>• 将所有 Broker（假设共 n 个 Broker）和待分配的 Partition 排序。<br>• 将第 i 个 Partition 分配到第（i mod n）个 Broker 上 （这个就是 Leader）。<br>• 将第 i 个 Partition 的第 j 个 Replica 分配到第（(i + j) mode n）个 Broker 上。<br><br><br>

简化Kafka设计

消费者根据自身消费能力控制消费速度

消费者可以按需选择消费模式：批量、重复、回溯历史、指定时间段

https://blog.csdn.net/qq_37502106/article/details/80271800<br>