首页IT科技kafka常见问题及解决(Kafka 常见问题)

kafka常见问题及解决(Kafka 常见问题)

时间2025-09-19 12:19:46分类IT科技浏览5043
导读:Kafka 常见问题...

Kafka 常见问题

    一年将尽夜                ,万里未归人                。

1                、Kafka 简介

Kafka适合离线和在线消息消费                      ,Kafka消息保留在磁盘上, 并在群集内复制以防止数据丢失                      。
Kafka构建在ZooKeeper同步服务之上        ,依赖 Zookeeper            ,它与Apache Storm和Spark非常好地集成, 用于实时流式数据分析        。
Kafka 依赖于日志顺序写, 因此支持消息回溯和支撑高性能读写            。

2                      、Kafka 的 Broker 基本概念

Kafka的 Server包含多个 Topic         、Partition 和 Replica                      ,负责协调 Producer 和 Consumer                      。主从结构为: 主节点为 Controller, 从节点为从节点 Kafka 启动是会往 Zookeeper 中注册当前Broker 信息            ,谁先注册谁就是 Controller        ,读取注册上来的从节点的数据(通过监听机制), 生成集群的元数据信息, 之后把这些信息都分发给其他的服务器, 让其他服务器能感知到集群中其它成员的存在

3            、Kafka 的 Topic 基本概念

标准 MQ 中的 Queue                      ,Kafka 中一个 Topic 的消息会保存在不同的 Partition (不同的 Broker)来保证高可用            。

4                      、Kafka 的 Partition (分区) 基本概念

可以理解为将标准 MQ 的 Queue 的消息进行拆分, 来实现高可用        。 Producer 发送的 Message, 根据 key 和 partition 数进行 hash, 然后进行投递                      。 一个分区只能被同一个 Consumer Group 中的一个 Consumer 消费               ,分区内消费有序               。

5            、Replica (备份)

每一个 Partition 的备份    。
Replica 的小于等于 Broker 的数量                       。
Leader: Replica领导节点, 每一个 Partition 都有对应的 Leader 节点(Broker)    ,Producer 写数据时, 只会往 Leader 中写                       ,Consumer 读数据也是从 Leader 中读                  。
Follower: Replica跟随节点, 用于复制领导节点的数据                  ,复制 Leader 消息采用 pull (拉)模式。        、
# Broker 设置副本数量 默认为 3 default.replication.factor # Topic 设置副本数量 replication-factor

6                      、ISR (In-Sync Replica)

Leader维护一个与其基本保持同步的Replica列表, 每个Partition都会有一个ISR, 而且是由leader动态维护                    。如果一个flower比一个leader落后太多, 或者超过一定时间未发起数据复制请求, 则leader将其重ISR中移除                      。当ISR中所有Replica都向Leader发送ACK时, leader才commit    。
Leader 宕机之后, 会从 ISR 选择数据最新的 Follower 来当做 Leader 如果 ISR 全部宕机, 则选择第一个回复的 Replica 当做 Leader 节点 (消息可能会丢失或者重复消费)                。

7               、水印备份机制

水印备份机制即 LEO (last end offffset),日志末端位移, 记录了该副本对象底层日志文件中下一条消息的位移值, 副本写入消息的时候, 会自动更新 LEO 值 Leader 会保存两个 LEO 值, 一个是自己的 LEO 值, 另外一个是 remote 的 LEO 值                      。Follower 每次 fetch 请求都会携带当前 LEO, Leader 会选择最小的 LEO来更新 HW
HW (high watermark): 从名字可以知道, 该值叫高水印值, HW 一定不会大于 LEO 值, 小于 HW 值的消息被认为是"已提交"或"已备份"的消息, 并对消费者可见        。

8    、Message

标准 MQ 的 Queue 中的 Message                    ,即一条消息            。

9                       、Producer

标准 MQ 中的发送方                      ,发送给 Broker 使用push (推)模式                      。

10                  、数据一致性保证 (消息不丢失)

request.required.asks=0
0: 相当于异步的, 不需要leader给予回复, producer立即返回, 发送就是成功,那么发送消息网络超时或broker crash(1.Partition的Leader还没有commit消息 2.Leader与Follower数据不同步), 既有可能丢失也可能会重发            。 1:当leader接收到消息之后发送ack, 丢会重发, 丢的概率很小        。 -1:当所有的follower都同步消息成功后发送ack. 不会丢失消息                      。

11、Consumer

标准 MQ 中的消费方    ,接受 Broker 使用 pull (拉)模式, 默认 100ms 拉一次                ,Consumer 消费的是Partition 的数据               。
消息丢失: 手动确认 ack 而不是自动提交    。
消息重复: 消费端幂等处理                       。

12                    、Consumer Group

在 Kafka 中, 一个 Topic 是可以被一个消费组消费, 一个Topic 分发给 Consumer Group 中的Consumer 进行消费, 保证同一条 Message 不会被不同的 Consumer 消费                  。
注意: 当Consumer Group的 Consumer 数量大于 Partition 的数量时, 超过 Partition 的数量将会拿不到消息。

13                      、分片规则

Kafka分配Replica的算法有两种: RangeAssignor 和 RoundRobinAssignor
默认为RangeAssignor:
1. 将所有Broker(假设共n个Broker)和待分配的Partition排序
2. 将第i个Partition分配到第(i mod n)个Broker上
3. 将第i个Partition的第j个Replica分配到第((i + j) mod n)个Broker上

14    、Rebalance (重平衡)

Rebalance 本质上是一种协议, 规定了一个 Consumer Group 下的所有 consumer 如何达成一致                      ,来分配订阅 Topic 的每个分区                    。
Rebalance 发生时, 所有的 Consumer Group 都停止工作, 直到 Rebalance 完成                      。

15                、Coordinator

Group Coordinator 是一个服务, 每个 Broker 在启动的时候都会启动一个该服务 GroupCoordinator 的作用是用来存储 Group 的相关 Meta 信息, 并将对应 Partition 的 Offset 信息记录到 Kafka 内置 Topic(__consumer_offsets)中 Kafka 在0.9之前是基于 Zookeeper 来存储Partition的 offset 信息(consumers/{group}/offsets/{topic}/{partition}), 因为 Zookeeper 并不适用于频繁的写操作, 所以在0.9之后通过内置 Topic 的方式来记录对应 Partition 的 offset    。

16                      、Rebalace 流程

Rebalance 过程分为两步:Join 和 Sync
1. Join: 顾名思义就是加入组                。这一步中, 所有成员都向 Coordinator 发送 JoinGroup 请求, 请求加入消费组        ,一旦所有成员都发送了 JoinGroup 请求, Coordinator 会从中选择一个Consumer 担任 Leader 的角色, 并把组成员信息以及订阅信息发给 Consumer Leader             ,注意Consumer Leader 和 Coordinator不是一个概念                      。Consumer Leader负责消费分配方案的制定        。
2. Sync: Consumer Leader 开始分配消费方案, 即哪个 Consumer 负责消费哪些 Topic 的哪些Partition            。一旦完成分配, Leader 会将这个方案封装进 SyncGroup 请求中发给 Coordinator,非 Leader 也会发 SyncGroup 请求, 只是内容为空                      。Coordinator 接收到分配方案之后会把方案塞进SyncGroup的Response中发给各个Consumer                      ,这样组内的所有成员就都知道自己应该消费哪些分区了            。

17        、日志索引

Kafka 能支撑 TB 级别数据, 在日志级别有两个原因: 顺序写和日志索引        。
Kafka 在一个日志文件达到一定数据量 (1G) 之后, 会生成新的日志文件, 大数据情况下会有多个日志文件, 通过偏移量来确定到某行纪录时, 如果遍历所有的日志文件, 那效率自然是很差的                      。Kafka在日志级别上抽出来一层日志索引, 来方便根据 offset 快速定位到是某个日志文件               。
每一个 partition 对应多个个 log 文件(最大 1G), 每一个 log 文件又对应一个 index 文件    。

18            、Kafka高性能                      、高吞吐 的原因?

分区            、顺序写        、批发送和数据压缩等                       。

19                      、分区的原因

如果我们假设像标准 MQ 的 Queue, 为了保证一个消息只会被一个消费者消费, 那么我们第一想到的就是加锁                  。对于发送者, 在多线程并且非顺序写环境下, 保证数据一致性, 我们同样也要加锁。一旦考虑到加锁, 就会极大的影响性能                    。我们再来看Kafka 的 Partition, Kafka 的消费模式和发送模式都是以 Partition 为分界            ,也就是说对于一个 Topic 的并发量限制在于有多少个 Partition, 就能支撑多少的并发        ,可以参考 Java 1.7 的 ConcurrentHashMap 的桶设计, 原理一样, 有多少桶, 支持多少的并发                      。

20               、顺序写

磁盘的顺序写的性能要比内存随机写的还要强    。

21    、批发送

批处理是一种常用的用于提高I/O性能的方式                。对Kafka而言, 批处理既减少了网络传输的Overhead, 又提高了写磁盘的效率                      。Kafka 0.82 之后是将多个消息合并之后再发送, 而并不是send一条就立马发送(之前支持)        。
# 批量发送的基本单位, 默认是16384Bytes, 即16kB batch.size # 延迟时间 linger.ms # 两者满足其一便发送

22                       、数据压缩

数据压缩的一个基本原理是, 重复数据越多压缩效果越好. 因此将整个Batch的数据一起压缩能更大幅度减小数据量, 从而更大程度提高网络传输效率Broker接收消息后                      ,并不直接解压缩               ,而是直接将消息以压缩后的形式持久化到磁盘 Consumer接受到压缩后的数据再解压缩            。
整体来讲: Producer 到 Broker, 副本复制, Broker 到 Consumer 的数据都是压缩后的数据, 保证高效率的传输                      。
一年将尽夜
万里未归人
声明:本站所有文章    ,如无特殊说明或标注                       ,均为本站原创发布            。任何个人或组织                  ,在未征得本站同意时,禁止复制                  、盗用、采集                    、发布本站内容到任何网站                      、书籍等各类媒体平台        。如若本站内容侵犯了原著者的合法权益                    ,可联系我们进行处理                      。

创心域SEO版权声明:以上内容作者已申请原创保护,未经允许不得转载,侵权必究!授权事宜、对本内容有异议或投诉,敬请联系网站管理员,我们将尽快回复您,谢谢合作!

展开全文READ MORE
电脑运行时cpu温度过高该如何解决呢(电脑运行时CPU温度过高该如何解决)