- zookeeper安装配置
- kafka安装配置
- jar包的版本要跟kafka版本匹配 官方文档
- kafka中文教程
- apache kafka技术分享系列(目录索引)
- 源码解析
-
Q:producer消息丢失处理?
-
A:通过配置清单来规避producer端的消息丢失:
- block.on.buffer.full = true 使得producer将一直等待缓冲区直至其变为可用
- acks=all 所有follower都响应了才认为消息提交成功
- retries = MAX 无限重试
- 使用KafkaProducer.send(record, callback)而不是send(record)方法 自定义回调逻辑处理消息发送失败
- replication.factor >= 3 这个完全是个人建议了,参考了Hadoop及业界通用的三备份原则
- min.insync.replicas > 1 消息至少要被写入到这么多副本才算成功,也是提升数据持久性的一个参数。与acks配合使用
-
Q:producer消息乱序处理?
-
A:max.in.flight.requests.per.connection=1 限制客户端在单个连接上能够发送的未响应请求的个数。设置此值是1表示kafka broker在响应请求之前client不能再向同一个broker发送请求 顺序消息
-
Q:producer分区策略?
-
A:producer分区数,它实际上是用多个线程并发地向不同分区所在的broker发起Socket连接同时给这些分区发送消息。分区数越多,内存和线程所消耗的资源就越多,所需要打开状态的文件句柄就越多,降低可用性
-
Q:consumer消息丢失处理?
-
A:首先要了解消息传输,主要分这几种情况:
- commit后处理消息,消息会丢失
- commit前处理消息,消息可能会重复
- 为保证消息一定能处理且仅处理一次,需要consumer做额外的保证工作(两阶段提交或TCC提交事务)
- 创建topic
bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 3 --partitions 3 --topic topic_0511
- 查看topic列表
bin/kafka-topics.sh --list --zookeeper localhost:2181
- 删除topic
- 查看某个topic的信息
bin/kafka-topics.sh --describe --zookeeper localhost:2181 --topic topic_0511
- 验证消息生产成功
bin/kafka-run-class.sh kafka.tools.GetOffsetShell --broker-list localhost:9092 --topic topic_0511_2 --time -1
- 查看topic消费情况
0.9之前:
bin/kafka-run-class.sh kafka.tools.ConsumerOffsetChecker --group test --topic topic_0508 --zookeeper localhost:2181
0.9之后版本:bin/kafka-consumer-groups.sh --bootstrap-server localhost:9092 -describe --new-consumer -group test
消费组在运行状态中 - 更改topic分区情况
bin/kafka-topics.sh --zookeeper localhost:2181 --alter --partitions 20 --topic topic_0508
- 查看__consumer_offsets中的信息
- 消费组相关解析
- 查询
__consumer_offsets
topic所有内容bin/kafka-console-consumer.sh --topic __consumer_offsets --zookeeper localhost:2181 --formatter "kafka.coordinator.GroupMetadataManager\$OffsetsMessageFormatter" --consumer.config config/consumer.properties --from-beginning
- 获取指定consumer group的位移信息
bin/kafka-simple-consumer-shell.sh --topic __consumer_offsets --partition 11 --broker-list localhost:9092 --formatter "kafka.coordinator.GroupMetadataManager\$OffsetsMessageFormatter"
-
元数据接口(Metadata api)
- TopicMetadataRequest
- TopicMetadataResponse
-
生产接口(Produce API)
- ProducerRequest
- ProducerResponse
-
获取消息接口(Fetch API) 用于获取一些Topic分区的一个或多个的日志块。
- FetchRequest
- FetchResponse
-
提交offset的方式
- OffsetCommitRequest
- OffsetCommitResponse
-
获取offset的方式
- OffsetFetchRequest
- OffsetFetchResponse
- Q:并发度问题
- A:storm集群里的1台物理机器会启动1个或多个worker(JVM)进程,所有的topology将在这些worker进程里被运行,在一个单独的worker进程里会运行1个或多个executor线程。每个executor只会运行1个topology的1个component(spout或bolt)的task实例,1个task最终完成数据处理的实体单元
parallelism_hint
,它代表着一个组件的初executor(线程)始数量,所有component的executor数量就是整个topology的整体并行度 - Q:Nimbus单点问题
- A:出现单点故障概率低,因为nimbus进程不参与任务运行,本身是无状态的。nimbus通过Zookeeper记录所有supervisor节点的状态和分配给它们的task,如果nimbus发现某个supervisor没有上报心跳或已经不可达,它将会把分配给故障supervisor的task重新分配给其他节点。
- Q:消息保证机制
- A:利用Spout,Bolt以及Acker的组合可以实现At Most Once以及At Least Once语义,Storm在At Least Once的基础上进行了一次封装(Trident),从而实现Exactly Once语义
- Q:分组策略
- A:随机分组、按字段分组、广播..