python 操作Kafka (二十七)

应用往Kafka写数据的原因有很多：用户行为分析、日志存储、异步通信等。多样化的使用场景带来了多样化的需求：消息是否能丢失？是否容忍重复？消息的吞吐量？消息的延迟？

kafka介绍

Kafka属于Apache组织，是一个高性能跨语言分布式发布订阅消息队列系统[7]。它的主要特点有：

• 以时间复杂度O(1)的方式提供消息持久化能力，并对大数据量能保证常数时间的访问性能；
• 高吞吐率，单台服务器可以达到每秒几十万的吞吐速率；
• 支持服务器间的消息分区，支持分布式消费，同时保证了每个分区内的消息顺序；
• 轻量级，支持实时数据处理和离线数据处理两种方式。

1.1. 主要功能

根据官网的介绍，ApacheKafka®是一个分布式流媒体平台，它主要有3种功能：

1：发布和订阅消息流，这个功能类似于消息队列，这也是kafka归类为消息队列框架的原因

2：以容错的方式记录消息流，kafka以文件的方式来存储消息流

3：可以再消息发布的时候进行处理

1.2. 使用场景

1：在系统或应用程序之间构建可靠的用于传输实时数据的管道，消息队列功能

2：构建实时的流数据处理程序来变换或处理数据流，数据处理功能

kafka生产者

首先，创建ProducerRecord必须包含Topic和Value，key和partition可选。然后，序列化key和value对象为ByteArray，并发送到网络。

接下来，消息发送到partitioner。如果创建ProducerRecord时指定了partition，此时partitioner啥也不用做，简单的返回指定的partition即可。如果未指定partition，partitioner会基于ProducerRecord的key生成partition。producer选择好partition后，增加record到对应topic和partition的batch record。最后，专有线程负责发送batch record到合适的Kafka broker。

当broker收到消息时，它会返回一个应答（response）。如果消息成功写入Kafka，broker将返回RecordMetadata对象（包含topic，partition和offset）；相反，broker将返回error。这时producer收到error会尝试重试发送消息几次，直到producer返回error。

实例化producer后，接着发送消息。这里主要有3种发送消息的方法：

• 立即发送：只管发送消息到server端，不care消息是否成功发送。大部分情况下，这种发送方式会成功，因为Kafka自身具有高可用性，producer会自动重试；但有时也会丢失消息；
• 同步发送：通过send()方法发送消息，并返回Future对象。get()方法会等待Future对象，看send()方法是否成功；
• 异步发送：通过带有回调函数的send()方法发送消息，当producer收到Kafka broker的response会触发回调函数

以上所有情况，一定要时刻考虑发送消息可能会失败，想清楚如何去处理异常。

通常我们是一个producer起一个线程开始发送消息。为了优化producer的性能，一般会有下面几种方式：单个producer起多个线程发送消息；使用多个producer。

kafka消费者

kafka的消费模式总共有3种：最多一次，最少一次，正好一次。为什么会有这3种模式，是因为客户端处理消息，提交反馈（commit）这两个动作不是原子性。

1.最多一次：客户端收到消息后，在处理消息前自动提交，这样kafka就认为consumer已经消费过了，偏移量增加。
2.最少一次：客户端收到消息，处理消息，再提交反馈。这样就可能出现消息处理完了，在提交反馈前，网络中断或者程序挂了，那么kafka认为这个消息还没有被consumer消费，产生重复消息推送。
3.正好一次：保证消息处理和提交反馈在同一个事务中，即有原子性。

本文从这几个点出发，详细阐述了如何实现以上三种方式。

At-most-once（最多一次）

设置enable.auto.commit为ture
设置 auto.commit.interval.ms为一个较小的时间间隔.
client不要调用commitSync()，kafka在特定的时间间隔内自动提交。

At-least-once（最少一次）

方法一
设置enable.auto.commit为false
client调用commitSync()，增加消息偏移;

方法二
设置enable.auto.commit为ture
设置 auto.commit.interval.ms为一个较大的时间间隔.
client调用commitSync(),增加消息偏移;

Exactly-once（正好一次）

3.1 思路
如果要实现这种方式，必须自己控制消息的offset，自己记录一下当前的offset，对消息的处理和offset的移动必须保持在同一个事务中，例如在同一个事务中，把消息处理的结果存到mysql数据库同时更新此时的消息的偏移。
3.2 实现
设置enable.auto.commit为false
保存ConsumerRecord中的offset到数据库
当partition分区发生变化的时候需要rebalance，有以下几个事件会触发分区变化
1 consumer订阅的topic中的分区大小发生变化
2 topic被创建或者被删除
3 consuer所在group中有个成员挂了
4 新的consumer通过调用join加入了group
此时 consumer通过实现ConsumerRebalanceListener接口，捕捉这些事件，对偏移量进行处理。

consumer通过调用seek(TopicPartition, long)方法，移动到指定的分区的偏移位置。

参考：https://blog.csdn.net/laojiaqi/article/details/79034798

Broker

Kafka是一个高吞吐量分布式消息系统，采用Scala和Java语言编写，它提供了快速、可扩展的、分布式、分区的和可复制的日志订阅服务。它由Producer、Broker、Consumer三部分构成.

Producer向某个Topic发布消息，而Consumer订阅某个Topic的消息。 一旦有某个Topic新产生的消息，Broker会传递给订阅它的所有Consumer，每个Topic分为多个分区，这样的设计有利于管理数据和负载均衡。

• Broker：消息中间件处理结点，一个Kafka节点就是一个broker，多个broker可以组成一个Kafka集群。
• Controller：中央控制器Control，负责管理分区和副本状态并执行管理着这些分区的重新分配。（里面涉及到partition leader 选举）
• ISR：同步副本组

Topic

在Kafka中，消息是按Topic组织的.

• Partition:topic物理上的分组，一个topic可以分为多个partition，每个partition是一个有序的队列。
• Segment：partition物理上由多个segment组成
• offset：每个partition都由一系列有序的、不可变的消息组成，这些消息被连续的追加到partition中. partition中的每个消息都有一个连续的序列号叫做offset,用于partition唯一标识一条消息.

topic中partition存储分布

在Kafka文件存储中，同一个topic下有多个不同partition，每个partition为一个目录，partiton命名规则为topic名称+有序序号，第一个partiton序号从0开始，序号最大值为partitions数量减1。

├── data0
│   ├── cleaner-offset-checkpoint
│   ├── client_mblogduration-35
│   │   ├── 00000000000004909731.index
│   │   ├── 00000000000004909731.log           // 1G文件--Segment
│   │   ├── 00000000000005048975.index      // 数字是Offset
│   │   ├── 00000000000005048975.log
│   ├── client_mblogduration-37
│   │   ├── 00000000000004955629.index
│   │   ├── 00000000000004955629.log
│   │   ├── 00000000000005098290.index
│   │   ├── 00000000000005098290.log
│   ├── __consumer_offsets-33
│   │   ├── 00000000000000105157.index
│   │   └── 00000000000000105157.log
│   ├── meta.properties
│   ├── recovery-point-offset-checkpoint
│   └── replication-offset-checkpoint
123456789101112131415161718

• cleaner-offset-checkpoint:存了每个log的最后清理offset
• meta.properties: broker.id 信息
• recovery-point-offset-checkpoint:表示已经刷写到磁盘的记录。recoveryPoint以下的数据都是已经刷 到磁盘上的了。
• replication-offset-checkpoint: 用来存储每个replica的HighWatermark的(high watermark (HW)，表示已经被commited的message，HW以下的数据都是各个replicas间同步的，一致的。)

partiton中文件存储方式

每个partion(目录)由多个大小相等segment(段)数据文件中。但每个段segment file消息数量不一定相等，这种特性方便old segment file快速被删除。

每个partiton只需要支持顺序读写就行了，segment文件生命周期由服务端配置参数决定。

partiton中segment文件存储结构

partion中segment file组成和物理结构。

segment file组成：由2大部分组成，分别为index file和data file，此2个文件一一对应，成对出现，后缀".index"和“.log”分别表示为segment索引文件、数据文件.
segment文件命名规则：partion全局的第一个segment从0开始，后续每个segment文件名为上一个segment文件最后一条消息的offset值。数值最大为64位long大小，19位数字字符长度，没有数字用0填充。

以一对segment file文件为例，说明segment中index<—->data file对应关系物理结构如下

• Index文件存储大量元数据，指向对应log文件中message的物理偏移地址。
• log数据文件存储大量消息

其中以Index文件中元数据3,497为例，依次在数据文件中表示第3个message(在全局partiton表示第368772个message)、以及该消息的物理偏移地址为497。

下面看看segment data file的内部

segment data file由许多message组成，下面详细说明message物理结构如下：

关键字	解释说明
8 byte offset	该message在partition的offset
4 byte message size	message大小
4 byte CRC32	用crc32校验message
1 byte “magic”	表示本次发布Kafka服务程序协议版本号
1 byte “attributes”	表示为独立版本、或标识压缩类型、或编码类型。
4 byte key length	表示key的长度,当key为-1时，K byte key字段不填
K byte key	可选
value bytes payload	表示实际消息数据。

2.4 在partition中如何通过offset查找message

例如读取offset=368776的message，需要通过下面2个步骤查找。

1. 第一步查找segment file

• 上述图2为例，其中00000000000000000000.index表示最开始的文件，起始偏移量(offset)为0.第二个文件00000000000000368769.index的消息量起始偏移量为368770 = 368769 + 1.同样，第三个文件00000000000000737337.index的起始偏移量为737338=737337 + 1，其他后续文件依次类推，以起始偏移量命名并排序这些文件，只要根据offset 二分查找文件列表，就可以快速定位到具体文件。
  当o