kafka常见问题及解决(Kafka 常见问题)
导读: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
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版权声明:以上内容作者已申请原创保护,未经允许不得转载,侵权必究!授权事宜、对本内容有异议或投诉,敬请联系网站管理员,我们将尽快回复您,谢谢合作!