三、Kafka生产过程分析
1.写入方式
producer采用推（push）模式将消息发布到broker，每条消息都被追加（append）到分区（patition）中，属于顺序写磁盘（顺序写磁盘效率比随机写内存要高，保障kafka吞吐率）。
2.分区（Partition）
消息发送时都被发送到一个topic，其本质就是一个目录，而topic是由一些Partition Logs(分区日志)组成，其组织结构如下图所示：
[图片上传失败...(image-841a5d-1575963389728)]
[图片上传失败...(image-633ffb-1575963389728)]
我们可以看到，每个Partition中的消息都是==有序==的，生产的消息被不断追加到Partition log上，其中的每一个消息都被赋予了一个唯一的==offset值==。
分区的原因
- 方便在集群中扩展，每个Partition可以通过调整以适应它所在的机器，而一个topic又可以有多个Partition组成，因此整个集群就可以适应任意大小的数据了；
- 可以提高并发，因为可以以Partition为单位读写了。
分区的原则
[图片上传失败...(image-858f03-1575963389728)]
- 指定了patition,则直接使用;
- 未指定patition但指定key,将 key 的 hash 值与 topic 的 partition 数进行取余得到 partition 值;
- patition和key都未指定,第一次调用时随机生成一个整数（后面每次调用在这个整数上自增），将这个值与 topic 可用的 partition 总数取余得到 partition 值，也就是常说的 round-robin 算法。
3.副本（Replication）
- 同一个partition可能会有多个replication（对应 server.properties 配置中的 default.replication.factor=N）。
- 没有replication的情况下，一旦broker 宕机，其上所有 patition 的数据都不可被消费，同时producer也不能再将数据存于其上的patition。
- 引入replication之后，同一个partition可能会有多个replication，而这时需要==在这些replication之间选出一个leader，producer和consumer只与这个leader交互，其它replication作为follower从leader 中复制数据。==
4.写入流程
[图片上传失败...(image-8942a5-1575963389728)]
- producer先从zookeeper的 "/brokers/.../state"节点找到该partition的leader
- producer将消息发送给该leader
- leader将消息写入本地log
- followers从leader pull消息，写入本地log后向leader发送ACK
- leader收到所有ISR中的replication的ACK后，增加offset,并向producer发送ACK
5.数据可靠性保证
为保证producer发送的数据，能可靠的发送到指定的topic，topic的每个partition收到producer发送的数据后，都需要向producer发送ack（acknowledgement确认收到），如果producer收到ack，就会进行下一轮的发送，否则重新发送数据。
1.副本数据同步策略
| 方案 | 优点 | 缺点 |
|---|---|---|
| 半数以上完成同步，就发送ack | 延迟低 | 选举新leader时，容忍n台节点的故障，需要2n+1个副本 |
| 全部完成同步，才发送ack | 选举新leader时，容忍n台节点的故障，需要n+1个副本 | 延迟高 |
Kafka选择了第二种方案
- 同样为了容忍n台节点的故障，第一种方案需要2n+1个副本，而第二种方案只需要n+1个副本，而Kafka的每个分区都有大量的数据，第一种方案会造成大量数据的冗余。
- 虽然第二种方案的网络延迟会比较高，但网络延迟对Kafka的影响较小。
2.ISR
- Leader维护了一个动态的in-sync replica set (ISR)，意为和leader保持同步的follower集合。
- 当ISR中的follower完成数据的同步之后，leader就会给follower发送ack。
- 如果follower长时间未向leader同步数据，则该follower将被踢出ISR，该时间阈值由replica.lag.time.max.ms参数设定。
- Leader发生故障之后，就会从ISR中选举新的leader。
- 在0.9版本前有两个参数,一个消息数量,一个时间限定。去掉了消息数量(因为如果kafka某一批次数据量比限定的消息数量大,则ISR中的fllower全部被T掉)
3.ACKS
Kafka为用户提供了三种可靠性级别
0: producer不等待broker的ack,这一操作提供了一个最低的延迟,broker一接收到还没有写入磁盘就已经返回,当broker故障时有可能丢失数据。
1: producer等待broker的ack，partition的leader落盘成功后返回ack,如果在follower同步成功之前leader故障,那么将会丢失数据。
-1: producer等待broker的ack,partition的leader和follower全部落盘成功后才返回ack。但是如果在follower同步完成后,broker发送ack之前,leader发生故障,那么会造成数据重复。
4.Kafka故障处理
[图片上传失败...(image-7ac12-1575963389728)]
LEO：指的是每个副本最大的offset。
HW：指的是消费者能见到的最大的offset，ISR队列中最小的LEO。
follower故障
follower发生故障后会被临时踢出ISR，待该follower恢复后，follower会读取本地磁盘记录的上次的HW，并将log文件高于HW的部分截取掉，从HW开始向leader进行同步。==等该follower的LEO大于等于该Partition的HW==，即follower追上leader之后，就可以重新加入ISR了。
leader故障
leader发生故障之后，会从ISR中选出一个新的leader，之后，为保证多个副本之间的数据一致性，其余的follower会先将各自的log文件高于HW的部分截掉，然后从新的leader同步数据。
==注意：这只能保证副本之间的数据一致性，并不能保证数据不丢失或者不重复==。
5. 数据一致性
- ACK设置为-1可以保证不丢失数据,==但是，对于一些非常重要的信息，比如说交易数据，下游数据消费者要求数据既不重复也不丢失，即Exactly Once语义。==
- 0.11版本的Kafka，引入了一项重大特性：幂等性。所谓的幂等性就是指==Producer不论向Server发送多少次重复数据，Server端都只会持久化一条==。
enable.idompotence=true
- Producer在初始化的时候会被分配一个PID（Producer id），发往同一Partition的消息会附带Sequence Number。而==Broker端会对 <PID, Partition, SeqNumber> 做缓存，当具有相同主键的消息提交时，Broker只会持久化一条。==
- 但是==PID重启就会变化==，同时不同的Partition也具有不同主键，所以幂等性无法保证跨分区跨会话的Exactly Once。
6.数据一致性深入
- producer向topic发送message时,会随机初始化一个PID,但是PID是producer生成的,每次重启都会变更。
- 因此,会通过用户设置的tid其hash后与partition的数量取模后的那个分区partition-N,找到partition-N的leader。
- 通过该pid去继续执行操作,发送数据等事务。
