没有合适的资源?快使用搜索试试~ 我知道了~
kafka-0.8.1.1总结1
资源详情
资源评论
资源推荐
目录
一、 基础篇........................................................................................................................1
1. 开篇说明....................................................................................................................1
2. 概念说明....................................................................................................................1
3. 配置说明....................................................................................................................3
4. znode 分类 ...............................................................................................................17
5. kafka 协议分类 ........................................................................................................24
6. Kafka 线程................................................................................................................29
7. 日志存储格式..........................................................................................................30
8. kakfa 架构设计 ........................................................................................................35
二、 流程篇......................................................................................................................36
1、 kafka 启动过程.....................................................................................................36
2、 日志初始化和清理过程 ......................................................................................38
3、 选举 controller 过程 ............................................................................................39
4、 controller 处理 broker startup 过程 ....................................................................39
5、 controller 处理 broker failure 过程 .....................................................................40
6、 broker 成 leader、follower 过程.........................................................................41
7、 produce 过程........................................................................................................43
8、 新建 topic-partition 过程.....................................................................................44
9、 consume 过程 ......................................................................................................46
10、 controlled shutdown 过程................................................................................47
11、 preferred election 过程 ....................................................................................47
12、 reassignment 过程............................................................................................47
13、 topic config change 过程 ..................................................................................48
三、 工具篇......................................................................................................................48
四、 FAQ ...........................................................................................................................52
五、 监控篇......................................................................................................................53
一、 基础篇
1. 开篇说明
kafka 是一个分布式消息系统,具有高可用、高性能、分布式、高扩展、持久性等特性。
学好 kafka 对于理解分布式精髓意义重大,本文档旨在讲 kafka 的原理,对于 delete topic
等未实现的功能不会涉及,对于 log compaction 因为我没有研究也不会涉及。
2. 概念说明
✓ Topic
主题,声明一个主题,producer 指定该主题发布消息,订阅该主题的 consumer 对该主
题进行消费
✓ Partition
每个主题可以分为多个分区,每个分区对应磁盘上一个目录,分区可以分布在不同 broker
上,producer 在发布消息时,可以通过指定 partition key 映射到对应分区,然后向该分区
发布消息,在无 partition key 情况下,随机选取分区,一段时间内触发一次(比如 10 分
钟),这样就保证了同一个 producer 向同一 partition 发布的消息是顺序的
消费者消费时,可以指定 partition 进行消费,也可以使用 high-level-consumer
api,自动进行负载均衡,并将 partition 分给 consumer,一个 partition 只能被一个
consumer 进行消费。
✓ Producer
生产者,可以多实例部署,可以批量和单条发送,可以同步、异步(多个线程,1-N 个线程
做生产消息并放入队列,1 个线程做发送消息)发送。无论是异步还是同步发送,producer 对
于一个 broker 只用一个连接(符合 kafka 保证消息顺序的设计),由于只用一个连接,所以发
送线程只有一个,尝试用多线程 send 都是徒劳的。
✓ Consumer
消费者,可以多实例部署,可以批量拉取,有两类 API 可供选择,一个 simpleConsumer,
暴露所有的操作给用户,可以提交 offset、fetch offset、指定 partition fetch
message;另外一个 high-level-consumer(ZookeeperConsumerConnector),帮助用
户 做 基 于 partition 自 动 分 配 的 负 载 均 衡 , 定 期 提 交 offset, 建 立 消 费 队 列 等 。
simpleConsumer 相当于手动挡,high-level-consumer 相当于自动挡。
simpleConsumer 无需像 high-level-consumer 那样向 zk 注册 brokerid、owner,
甚至不需要提交 offset 到 zk,可以将 offset 提交到任意地方比如(mysql,本地文件)。
high-level-consumer,一个进程中可以启多个消费线程,一个消费线程即是一个
consumer, 假设 A 进 程里 有 2 个 线程 (consumerid 分别 为 1,2) ,B 线 程有 2 个 线程
(consumerid 分别为 1,2),topic1 的 partition 有 5 个,那么 partition 分配是这样
的:
partition1--->A 进程 consumerid1
partition2--->A 进程 consumerid1
partition3--->A 进程 consumerid2
partition4--->B 进程 consumer1
partition5--->B 进程 consumer2
✓ Group
High-level-consumer 可以声明 group,每个 group 可以有多个 consumer,每 group
各自管理各自的消费 offset,各个不同 group 之间互不关联影响。
由于目前版本消费的 offset、owner、group 都是 consumer 自己通过 zk 管理,所以
group 对于 broker 和 producer 并 不关心, 一些监 控工具 需要通过 group 来监 控,
simpleComsumer 无需声明 group
✓ Leader
每个 partition,都有一个 leader,0-N 个 follower,N=ReplicationFactor(复
制系数)-1,leader+follower=replica,in-sync-replica=isr
Leader 负 责 该 partition 的 client 的 读 (fetch) 请 求 和 写 (send) 请 求 以 及
follower 的读(fetch)请求
Leader 处理 follower 的 fetch 请求和 producer client 的 produce 请求(仅当
ack=-1 或 N)使用到了 Delayed response 机制(client 端长 polling,broker delay
response)。
当 fetch 请求先到来,事先 hold 住 fetch 请求,有 produce 请求并写入日志时通知队
列释放 fetch 请求的 response,同时 produce 请求也因 follower 同步了消息数据而得到
响应
Leader 负责管理 ISR 的状态,当 follower 所同步的消息赶上或者落后与 leader 某个
固定阀值,leader 将该 follower 拉进 isr(更新到 zk 上),长时间未发同步 fetch 请求或
者落后 offset 差值大于阀值,leader 就会将该 follower 从 isr 中移除
✓ Follower
follower 负 责 当 leader 失 联 后 做 故 障 恢 复 参 与 选 主 (leader) 和 备 份 用 , 成 为
follower 后,就启动 fetch 线程(一个 broker(leader)一个)不停的向 leader 同步消息
到本地
✓ ISR
处于同步状态的 follower 列表,是 in-sync-replica 的缩写,replica 分为二类:
一:处于同步状态的 replica 即 isr,二:处于离线状态的 replica
✓ Replica
Topic-partition 创建的时候分配的 replica,不管被分配为 replica 的 broker 有
没有 topic 消息数据,它始终都是 replica,保存在 zk /brokers/topics/[topic]节点
中,除非做 reassign
✓ Controller
Kafka 集群里面有一台broker 作为Controller,controller 检测broker failure、
进 行选 leader 操 作、 管 理 和同 步 topic-partition 元 数 据 和 replica 状 态到 各 个
broker、
Zk 上的 topic state 节点 leader 项及 leader epoch 完全由 controller 控制、在某个
broker 挂掉后,会做移除 isr 操作,reassign 和 preferred elec 及 delete topic 都
由 controller 来做。
每台 broker 启动时会竞争参选 controller,当发现已经有 controller 时,会自动放弃,
并监控/controller 节点,当/controller session 过期时再次竞争参选
✓ Offset
Offset 是相对于第一条消息的位移,第一条消息的 offset 是 0,在 log 文件中,offset
字 段 被 定 义 为 相 当 于 当 前 segment 的 位 移 , 比 如 当 前 segment 的 起 始 offset 是
00000006,那么第一消息的 offset 就是 00000001。
Consumer 和 follower 会传递 offset 字段给 leader,来获取 offset 之后的消息,
consumer 会将 offset 提交到 zk 上
endlogOffset--->指 topic-partition log 目录里面最后的一条消息的 offset
✓ HighWatermark
一个 partition 的 isr 列表中,所有 isr 列表里 broker 中同步的最低的那条消息
offset。和木桶原理一样,水位取决于最低那块短板,即 highwatermark 取决于最低的那条
offset。
那 highwatermark 在什么时候使用呢,在重新选 leader 的时候,follower 会将日志
trucate 至 highwatermark,然后再去主同步数据,这样能保证数据一致性,但是有可能消
息数据会丢失
✓ controllerEpoch
为了防止先发的请求后到来导致 broker 数据不一致,所以使用版本管理数据,每次更换
controller,epoch 加 1,所以 broker 永远只响应本次请求中 epoch>=上次请求 epoch
的请求。
✓ leaderEpoch
为了防止先发的请求后到来导致 broker 数据不一致,所以使用版本管理数据,每次选主
更换 leader,epoch 加 1,所以 broker 永远只响应本次请求中 epoch>=上次请求 epoch 的
请求
3. 配置说明
Server 端配置
目前对 topic 单独配置,除了 partition 和 replication.factor,就只有 logconfig
只影响 log。
其余的配置不支持动态修改,对于 topic 可以在创建的时候和修改的时候修改 log 相关
config,也可以通过 kafka 提供的脚本工具修改针对某个 topic 的 replication.factor
和 partition
https://cwiki.apache.org/confluence/display/KAFKA/Dynamic+Topic+C
onfig
Property
Default
Description
备注
broker.id
Each broker is uniquely
identified by a non-negative
integer id. This id serves as the
broker's "name" and allows the
broker to be moved to a different
host/port without confusing
consumers. You can choose any
number you like so long as it is
unique.
log.dirs
/tmp/kafk
a-logs
A comma-separated list of
one or more directories in which
Kafka data is stored. Each new
partition that is created will
be placed in the directory which
currently has the fewest
partitions.
当新 partition 创建
时它会进入
包含 partition 最少
的目录中
port
6667
The port on which the server
accepts client connections.
zookeeper.connect
null
Specifies the ZooKeeper
connection string in the
form hostname:port, where
hostname and port are the host
可以有一个 chroot
用于防止和 zk 其它业
务节点冲突
and port for a node in your
ZooKeeper cluster. To allow
connecting through other
ZooKeeper nodes when that host
is down you can also specify
multiple hosts in the
formhostname1:port1,hostname2
:port2,hostname3:port3.
ZooKeeper also allows you to
add a "chroot" path which will
make all kafka data for this
cluster appear under a
particular path. This is a way
to setup multiple Kafka clusters
or other applications on the
same ZooKeeper cluster. To do
this give a connection string in
the
formhostname1:port1,hostname2
:port2,hostname3:port3/chroot
/pathwhich would put all this
cluster's data under the
path /chroot/path. Note that
you must create this path
yourself prior to starting the
broker and consumers must use
the same connection string.
message.max.bytes
1000000
The maximum size of a message
that the server can receive. It
is important that this property
be in sync with the maximum fetch
size your consumers use or else
an unruly producer will be able
to publish messages too large
for consumers to consume.
单条 message 最大字
节数,consumers 在
fetchSize 至少要大
于该配置,不然有可能
会永远拿不到消息
num.network.threads
3
The number of network
threads that the server uses for
handling network requests. You
probably don't need to change
this.
做 NIO 操 作 ,
read/write from
socket
num.io.threads
8
The number of I/O threads
that the server uses for
executing requests. You should
have at least as many threads as
you have disks.
Request handler,
负责处理请求
background.threads
4
The number of threads to use
for various background
processing tasks such as file
deletion. You should not need to
change this.
用做定时任务,包括
1、cleanupLogs
2、flushDirtyLogs
3、
checkpointRecove
ryPointOffsets
4、
checkpointHighWa
termarks
5、maybeShrinkIsr
异步执行一次,包括
剩余54页未读,继续阅读
H等等H
- 粉丝: 31
- 资源: 337
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功
评论0