本文主要向大家介绍了【云计算】kafka之数据生产流程，数据复制与ReplicaFailover解析，通过具体的内容向大家展现，希望对大家学习云计算有所帮助。

数据生产流程

1.发送到kafka的数据会封装为ProducerRecord对象，包含topic、partition、key、value信息;

2.调用send()方法后，将数据序列化为字节数组，如果没有指定分区 ，那么分区器会根据ProducerRecord 对象的键来计算一个分区;

3.当消息达到一个批次设定的量(消息放在缓冲区中)，通过网络发送到不同的主题，不同的分区;

4.如果消息成功写入 Kafka，就返回 一 个

RecordMetaData 对象，它包含了主题和分区信息，以及记录在分区里的偏移量。如果写入

失败， 则告知生产者尝试重新发送消息，达到最大重试次数就抛出异常。

数据复制

第一个注册到Zookeeper的broker为Contrllor,除了具有一般 broker 的功能之外，还负责加入集群的broker上的分区首领的选举(以及离开集群的broker上的首领分区的重新选举)。

kafka中，每一个partition，有一个leader(所以集群并不是一定只有一个leader，可能有多个leader)，其他follower去拉取数据。

考虑到数据的一致性，Kafka中，消费者只能读取被commit的数据，因为如果允许消费者读取非commit的数据，考虑消费者1读取机器A中的数据，而该数据只有A和leader中有数据，其他flower还没与pull复制，这个时候leader和A挂了，此时别的消费者就读取不到，从而数据不一致。

副本有“首领副本”和“跟随者副本”的概念(LSR就与它们有关)：为了保证一致性，所有生产者请求和消费者请求都会经过首领副本。

【跟随者副本不处理来自客户端的请求，它们唯一的任务就是从首领那里复制消息，保持与首领一致的状态。】

一个partition物理上由多个segment组成，每个Segment存着message信息(每个partiton为一个目录)数据过期清除，就是以segment为单位，分区的复制设置：offsets.topic.replication.factor。

partition的命名规则为：topic名称+有序序号，第一个序号从0开始计，最大的序号为partition数量减1 每个partition(目录)相当于一个巨型文件被平均分配到多个大小相等的segment(段)数据文件中(每个segment 文件中消息数量不一定相等)这种特性也方便old segment的删除，即方便已被消费的消息的清理，提高磁盘的利用率。每个partition只需要支持顺序读写就行，segment的文件生命周期由服务端配置参数(log.segment.bytes，log.roll.{ms,hours}等若干参数)决定。 segment文件由两部分组成，分别为“.index”文件和“.log”文件，分别表示为segment**索引文件和数据文件**。这两个文件的命令规则为：partition全局的第一个segment从0开始，后续每个segment文件名为上一个segment文件最后一条消息的offset值，数值大小为64位，20位数字字符长度，没有数字用0填充

Kafka 的消息复制机制一般只能在单个集群里进行。

Kafka 提供了 一 个叫作 MirrorMaker 的工具，可以用它来实现集群间的消息复制。

2. leader会维护一个与leader同步的Replica列表(ISR)，当其发现某一flower的复制的列表落后太多，或者超时没有发起拉取请求，会将其从ISR中移除。换句话说，leader负责维护和跟踪ISR(In-Sync Replicas)中所有follower滞后的状态

3. 剔除出ISR依靠延迟时间replica.lag.time.max.ms和延迟条数replica.lag.max.messages两个维度, 当前最新的版本0.10.x中只支持replica.lag.time.max.ms这个维度)，任意一个超过阈值都会把follower剔除出ISR, 存入OSR(Outof-Sync Replicas)列表。也就是说，总副本数=ISR中副本+OSR中副本

副本、拉取、多leader图：(图片源自网络)：

数据可靠性

1.producer向leader发送数据时，可以通过request.required.acks参数来设置数据可靠性的级别：

1(默认)：这意味着producer在ISR中的leader已成功收到的数据并得到确认后发送下一条message。如果leader宕机了，则会丢失数据。(可以理解为更偏向于同步复制) 0：这意味着producer无需等待来自broker的确认而继续发送下一批消息。这种情况下数据传输效率最高，但是数据可靠性确是最低的。(可以理解为更偏向于异步复制) -1：producer需要等待ISR中的所有follower都确认接收到数据后才算一次发送完成，可靠性最高。但是这样也不能保证数据不丢失，比如当ISR中只有leader时

所以数据可靠性要求极高时，可设置该参数值为-1 Topic的参数min.insync.replicas当request.required.acks参数设置为-1时，才生效。表示ISR中的最小副本数是多少，如果ISR中的副本数少于min.insync.replicas配置的数量时，客户端会返回异常：org.apache.kafka.common.errors.NotEnoughReplicasExceptoin 我们也很有必要将上方的两个参数结合使用，因为在min.insync.replicas设置为1时，leader挂掉，就没有备份的数据了(其他flower还没来得及去pull)

2.Kafka 可以保证分区消息的顺序(对于单个分区而言)

3.只有当消息被写入分区的所有同步副本时(但不一定要写入磁盘)，它才被认为是“已提交”的，否则，broker不认为它正确接受了此消息。消费者只能读取已经提交的悄息。

4.上方提到的消息分本的复制策略。

Replica Failover

部分宕机

1.第一次LSR中有A、B、C、三个server(leader+flower)，此时只有m1可以commit。

2.leader A挂掉，产生新的leader B，commit m2

4.A恢复，发现落后的数量小于参数设定值，会catch up——重新pull m2、m4、m5

5.flower的恢复类似，只是说flower挂掉后不重新选举leader

m3的恢复?

因为m3从来没有被commit，所以producer会retry发送

所以kafka不能保证消费者消费的数据时producer发送的数据，消费者消费数据的顺序是leader们commit的顺序!!!

全部宕机

假设9台机器，全部宕机前5台机器在LSR中：

1.等待之前在LSR中的任一一台机器恢复。一致性好。(CAP之consistency)

2.等待9台机器任意一台恢复，设置为leader。高可用性。(默认)(CAP之Availability)

本文由职坐标整理并发布，希望对同学们有所帮助。了解更多详情请关注职坐标大数据云计算大数据安全频道！