Kafka
2016-01-08 12:58:33 21 举报
Kafka是一个分布式流处理平台,由LinkedIn开发并开源。它主要用于构建实时数据管道和流应用。Kafka的核心是一个发布/订阅消息系统,使应用程序能够通过一个共享的、持久的日志进行通信。这种设计模式使得Kafka具有高吞吐量、可扩展性和容错性。Kafka的主要组件包括生产者、消费者和Zookeeper集群。生产者负责将消息发送到特定的主题,消费者则从主题中读取消息。Zookeeper用于管理和协调Kafka集群中的 broker。Kafka广泛应用于大数据处理、实时分析、日志收集和流式处理等领域。
作者其他创作
大纲/内容
P22
P21
1. Fetch Data
P23
1. 一般在一个ConsumerGroup里面不能出现两个Consumer消费同一个Topic的同一个Partition里面的消息,因为这样会引起悲观锁竞争。
18.一个消息如何算投递成功,Kafka提供了三种模式:- 第一种是啥都不管,Producer发送出去就当作成功,这种情况当然不能保证消息成功投递到broker;- 第二种是Master-Slave模型,只有当Master和所有Slave都接收到消息时,才算投递成功,这种模型提供了最高的投递可靠性,但是损伤了性能;- 第三种模型,即只要Master确认收到消息就算投递成功;实际使用时,根据应用特性选择,绝大多数情况下都会中和可靠性和性能选择第三种模型
P24
1.消息传输三种一致性:1). 最多1次:可能会出现数据丢失情况;步骤为:a)先fetch data;2. 在zk上更新offet;3. 处理获取的data;如果offset++了但是数据处理失败,那么数据丢失;
Consumer
C4
Topic2
P12
Zk3
Broker1
Zk1
C1
P14
3).恰好1次:并不是指真正只传输1次,只不过有一个机制。确保不会出现“数据被重复处理”和“数据丢失”的情况
Zk
ConsumerThread14
P13
2.Process Data
2.当启动一个consumer group去消费一个topic的时候,无论topic里面有多个少个partition,无论我们consumer group里面配置了多少个consumer thread,这个consumer group下面的所有consumer thread一定会消费全部的partition
14. 一般来说,(1)一个Topic的Partition数量大于等于Broker的数量,可以提高吞吐率。(2)同一个Partition的Replica尽量分散到不同的机器,高可用;(3)partition的replica副本数目不能大于kafka broker节点的数目,否则报错。replica副本数包括一个leader,其他的就是copy副本
Topic1
Producer
16. partition也有leader和follower之分。leader是主partition,producer写kafka的时候先写partition leader,再由partition leader push给其他的partition follower。partition leader与follower的信息受Zookeeper控制
P11
17. Topic分配partition和partition replica的算法:(1)将Broker(size=n)和待分配的Partition排序。(2)将第i个Partition分配到第(i%n)个Broker上。(3)将第i个Partition的第j个Replica分配到第((i + j) % n)个Broker上
3.Process Data
C3
ConsumerThread21
8.Kafka producer不维护Offset信息,由Consumer来维护。high level api是维护在Zookeeper上,low level api是自己的程序维护。
Zk2
... ...
3. Offset++
2.至少同步数据到一个Follower
6.所以线上的分布式部署多个service服务,每个service里面的kafka consumer数量都小于对应的topic的partition数量,但是所有服务的consumer数量之和等于partition的数量。
2).最少1次:可能会重传数据,有可能出现数据被重复处理的情况;步骤为:a).先fetch data;b)处理data;c)更新offset;如果处理data完成,但更新offset失败则会导致消息重复处理。
11.在物理结构上,每个partition对应一个物理的目录(文件夹),文件夹命名是[topicname]_[partition]_[序号],一个topic可以有无数多的partition
1.写数据
ConsumerThread24
3.同步数据到Follower
ConsumerGroup2
2. Offset++
C2
5.Consumer Rebalance的触发条件:(1)Consumer增加或删除(2)Broker的增加或者减少
Service1
ServiecGroup
ConsumerThread22
10.producer端发送的message必须指定是发送到哪个topic,但是不需要指定topic下的哪个partition,因为kafka会把收到的message进行load balance,均匀的分布在这个topic下的不同的partition上( hash(message) % [broker数量] )
3.ACK
Service2
ConsumerThread11
2.立马ACK
7. 如果producer的流量增大,当前的topic的parition数量=consumer数量,这时候的应对方式就是横向扩展:增加topic下的partition,同时增加这个consumer group下的consumer。
19.Partition ack:当ack=1,表示producer写partition leader成功后,broker就返回成功,无论其他的partition follower是否写成功。当ack=2,表示producer写partition leader和其他一个follower成功的时候,broker就返回成功,无论其他的partition follower是否写成功。当ack=-1[parition的数量]的时候,表示只有producer全部写成功的时候,才算成功,kafka broker才返回成功信息。(当ACK>0时,代表至少有多少个replica写入成功才返回)
20.每个log entry格式为\"4个字节的数字N表示消息的长度\" + \"N个字节的消息内容\
ConsumerThread12
ConsumerGroup1
ConsumerThread23
13. 当add a new partition的时候,partition里面的message不会重新进行分配,原来的partition里面的message数据不会变,新加的这个partition刚开始是空的,随后进入这个topic的message就会重新参与所有partition的load balance
ConsumerThread13
4.同步到其他follower
12.在kafka配置文件中可随时更改num.partitions参数来配置更改topic的partition数量,在创建Topic时通过参数指定parittion数量,Topic创建之后通过Kafka提供的工具也可以修改partiton数量。
3.最优的设计就是,consumer group下的consumer thread的数量等于partition数量,这样效率是最高的
4.我们在设定consumer group的时候,只需要指明里面有几个consumer数量即可,无需指定对应的消费partition序号,consumer会自动进行rebalance。
0 条评论
下一页