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。