Kafka原理解析

最新推荐文章于 2022-03-30 09:52:39 发布

anboyyd

最新推荐文章于 2022-03-30 09:52:39 发布

阅读量204

点赞数

本文链接：https://blog.csdn.net/anboyyd/article/details/104963871

版权

1. 应用场景

适合于日志／网站性能采集等场景。Kafka不能严格保证消息的可靠性，所以适用于一些对消息重复消费或丢失可以容忍的场景。
适合于对吞吐量要求比较大的场景，不适合实时性很高的场景，它的性能主要依据于producer会buffer数据，一次性发送和consumer会一次性拉取一批数据进行消费。
适合于大数据的场景，它有很好的扩展性和性能优势。
大批量发送消息。

2. 产品特性

只支持订阅模式，根据消费者设置的group进行负载均衡。不同group消费相同的数据。
消息被消费后不会被删除，有两种删除方案，基于时间和基于partition大小。
消息的消费根据offset进行消费，offset保存在客户端，可以设置offset消费任意位置的消息，每次消费完一条消息offset加1，定期存储offset到zookeeper，如果保存前系统宕机，重启后会根据上次保存offset消费。消息消费的时间复杂度为o(1)
负载均衡策略，同一个group中的consumer可以消费一个或多个partition，一个partition只能被一个consumer消费。如果consumer>partition，多出的cunsumer不会参与消费。
kafka不能保证消息必须消费一次。它根据客户端的策略，可以做到最多消费一次和至少消费一次。实现方式是在接收到消息后立刻提交offset或处理完消息提交offset。
不易于一个partition有很多数据，consumer根据partition进行消费，如果partition个数很少，即使再多的consumer也不会提升消费性能。
kafka支持多份存储保证数据的可靠性，基于partition进行备份个数配置。在zookeeper上保存主和从partition关系，只有主提供服务，每次写入数据默认所有从写完才算完成，但productor可以选择等m个从partition提交后可以返回。流程如下。
producer通过zookeeper获取主partition，写入数据，主本地保存。
从partition从主pull数据，向主发ack，然后写入本地。
收到所有从（或producer指定个数）的ack，向producer发ack。
选主，通过选择一个broke做为controller和zookeeper相连，通过watch感知挂掉的机器。通过分析机器中的partition来计算新的主节点，并通过rpc通知其他broker。当然同样会设计controller的选主。
路由，发送消息是有一个key，根据key做路由选择，可以实现Partitioner接口来实现路由策略。
kakfa消息基于partition序进行消费，每个partition对应一个物理的目录，顺序消费日志。
kakfa基于文件进行存储，它的性能主要来自于producer缓存数据批量提交和consumer预取批量数据。同时在写入文件前也会做缓存以提升性能。

3. 架构

整体架构

zookeeper架构

4. 存储

一个topic有多个partition，每个partition有一个目录。
一个目录中包含一个active segment list文件和一系列segment文件。
active segment list中的每一行存储

5. 性能评估

Kafka单机写入TPS约在百万条/秒，消息大小10个字节。Kafka的TPS跑到单机百万，主要是由于Producer端将多个小消息合并，批量发向Broker。

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

缺点：

客户端大量缓存数据，gc压力增大
Producer调用发送消息接口，消息未发送到Broker，向业务返回成功，此时Producer宕机，会导致消息丢失，业务出错。