- 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:21810.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_offsetstopic所有内容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:随机分组、按字段分组、广播..