Kafka机制

Topic
Topic是Kafka数据写入操作的基本单元，可以指定副本
一个Topic包含一个或多个Partition，建Topic的时候可以手动指定Partition个数，个数与服务器个数相当
每条消息属于且仅属于一个Topic
Producer发布数据时，必须指定将该消息发布到哪个Topic
Consumer订阅消息时，也必须指定订阅哪个Topic的信息

Kafka中的Message是以topic为基本单位组织的，不同的topic之间是相互独立的。每个topic又可以分成几个不同的partition(每个topic有几个partition是在创建topic时指定的 bin/kafka-topics.sh --create --zookeeper hdp-1:2181 --replication-factor 1 --partitions 1 --topic animal)，每个partition存储一部分Message。借用官方的一张图，可以直观地看到topic和partition的关系。

partition是以文件的形式存储在文件系统中，比如，创建了一个名为page_visits的topic，其有5个partition，那么在Kafka的数据目录中(由配置文件中的log.dirs指定的)中就有这样5个目录: page_visits-0， page_visits-1，page_visits-2，page_visits-3，page_visits-4，其命名规则为<topic_name>-<partition_id>，里面存储的分别就是这5个partition的数据。

kafka的几个概念：
Broker：消息中间件处理结点，一个Kafka节点就是一个broker，多个broker可以组成一个Kafka集群；
Topic：一类消息，例如page view日志、click日志等都可以以topic的形式存在，Kafka集群能够同时负责多个topic的分发；
Partition：topic物理上的分组，一个topic可以分为多个partition，每个partition是一个有序的队；
Segment：每个partition又由多个segment file组成；
offset：每个partition都由一系列有序的、不可变的消息组成，这些消息被连续的追加到partition中。partition中的每个消息都有一个连续的序列号叫做offset，用于partition唯一标识一条消息；
message：这个算是kafka文件中最小的存储单位，即是 a commit log。

接下来，本文将分析partition目录中的文件的存储格式和相关的代码所在的位置。
Partition的数据文件
Partition中的每条Message由offset来表示它在这个partition中的偏移量，这个offset不是该Message在partition数据文件中的实际存储位置，而是逻辑上一个值，它唯一确定了partition中的一条Message。因此，可以认为offset是partition中Message的id。partition中的每条Message包含了以下三个属性：

offset
MessageSize
data

其中offset为long型，MessageSize为int32，表示data有多大，data为message的具体内容。它的格式和Kafka通讯协议中介绍的MessageSet格式是一致。

Partition的数据文件则包含了若干条上述格式的Message，按offset由小到大排列在一起。它的实现类为FileMessageSet，类图如下：

它的主要方法如下：

1. append: 把给定的ByteBufferMessageSet中的Message写入到这个数据文件中。
2. searchFor:
   从指定的startingPosition开始搜索找到第一个Message其offset是大于或者等于指定的offset，并返回其在文件中的位置Position。它的实现方式是从startingPosition开始读取12个字节，分别是当前MessageSet的offset和size。如果当前offset小于指定的offset，那么将position向后移动LogOverHead+MessageSize（其中LogOverHead为offset+messagesize，为12个字节）。
3. read：准确名字应该是slice，它截取其中一部分返回一个新的FileMessageSet。它不保证截取的位置数据的完整性。
4. sizeInBytes: 表示这个FileMessageSet占有了多少字节的空间。
5. truncateTo: 把这个文件截断，这个方法不保证截断位置的Message的完整性。
6. readInto: 从指定的相对位置开始把文件的内容读取到对应的ByteBuffer中。

我们来思考一下，如果一个partition只有一个数据文件会怎么样？

• 新数据是添加在文件末尾（调用FileMessageSet的append方法），不论文件数据文件有多大，这个操作永远都是O(1)的。
• 查找某个offset的Message（调用FileMessageSet的searchFor方法）是顺序查找的。因此，如果数据文件很大的话，查找的效率就低。
  那Kafka是如何解决查找效率的的问题呢？有两大法宝：1) 分段 2) 索引
  数据文件的分段
  Kafka解决查询效率的手段之一是将数据文件分段，比如有100条Message，它们的offset是从0到99。假设将数据文件分成5段，第一段为0-19，第二段为20-39，以此类推，每段放在一个单独的数据文件里面，数据文件以该段中最小的offset命名。这样在查找指定offset的Message的时候，用二分查找就可以定位到该Message在哪个段中。
  为数据文件建索引
  数据文件分段使得可以在一个较小的数据文件中查找对应offset的Message了，但是这依然需要顺序扫描才能找到对应offset的Message。为了进一步提高查找的效率，Kafka为每个分段后的数据文件建立了索引文件，文件名与数据文件的名字是一样的，只是文件扩展名为.index。
  索引文件中包含若干个索引条目，每个条目表示数据文件中一条Message的索引。
  索引包含两个部分（均为4个字节的数字），分别为相对offset和position。
• 相对offset：因为数据文件分段以后，每个数据文件的起始offset不为0，相对offset表示这条Message相对于其所属数据文件中最小的offset的大小。举例，分段后的一个数据文件的offset是从20开始，那么offset为25的Message在index文件中的相对offset就是25-20
  = 5。存储相对offset可以减小索引文件占用的空间。
• position，表示该条Message在数据文件中的绝对位置。只要打开文件并移动文件指针到这个position就可以读取对应的Message了。

index文件中并没有为数据文件中的每条Message建立索引，而是采用了稀疏存储的方式，每隔一定字节的数据建立一条索引。这样避免了索引文件占用过多的空间，从而可以将索引文件保留在内存中。但缺点是没有建立索引的Message也不能一次定位到其在数据文件的位置，从而需要做一次顺序扫描，但是这次顺序扫描的范围就很小了。

在Kafka中，索引文件的实现类为OffsetIndex，它的类图如下：

主要的方法有：

• append方法，添加一对offset和position到index文件中，这里的offset将会被转成相对的offset。
• lookup, 用二分查找的方式去查找小于或等于给定offset的最大的那个offset

最后：
我们以几张图来总结一下Message是如何在Kafka中存储的，以及如何查找指定offset的Message的。
Message是按照topic来组织，每个topic可以分成多个的partition，比如：有5个partition的名为为page_visits的topic的目录结构为：

partition是分段的，每个段叫LogSegment，包括了一个数据文件和一个索引文件，下图是某个partition目录下的文件：

可以看到，这个partition有4个LogSegment。
segment文件由两部分组成，分别为 .index文件和.log文件，分别表示为segment索引文件和数据文件。这两个文件的命令规则为：partition全局的第一个segment从0开始，后续每个segment文件名为上一个segment文件最后一条消息的offset值，数值大小为64位，20位数字字符长度，没有数字用0填充

00000000000000000000.index
00000000000000000000.log
00000000000000000000.timeindex
00000000000000170410.index
00000000000000170410.log
00000000000000170410.timeindex
00000000000000239430.index
00000000000000239430.log
00000000000000239430.timeindex

以上面的segment文件为例，展示出segment:00000000000000170410的.index文件和.log文件的对应的关系，如下图：

如何查找Message、
如上，.index索引文件存储大量的元数据，.log数据文件存储大量的消息，索引文件中的元数据指向对应数据文件中message的物理偏移地址(也就是实际的偏移地址，因为会涉及到segment文件清理)。其中以.index索引文件中的元数据[3, 348]为例，在.log数据文件表示第3个消息，即在全局partition中offset为170410+3=170413，该消息的物理偏移地址为348。
以上图为例，读取offset=170418的消息，首先查找segment文件，其中00000000000000000000.index为最开始的文件，第二个文件为00000000000000170410.index(起始偏移为170410+1=170411)，而第三个文件为00000000000000239430.index（起始偏移为239430+1=239431），所以这个offset=170418就落到了第二个文件之中。其他后续文件可以依次类推，以其实偏移量命名并排列这些文件，然后根据二分查找法就可以快速定位到具体文件位置。其次根据00000000000000170410.index文件中的[8,1325]定位到00000000000000170410.log文件中的1325的位置进行读取

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

1、查找segment file
00000000000000000000.index表示最开始的文件，起始偏移量(offset)为0

00000000000000368769.index的消息量起始偏移量为368770 = 368769 + 1

00000000000000737337.index的起始偏移量为737338=737337 + 1

其他后续文件依次类推。

以起始偏移量命名并排序这些文件，只要根据offset 二分查找文件列表，就可以快速定位到具体文件。当offset=368776时定位到00000000000000368769.index和对应log文件。

2、通过segment file查找message
当offset=368776时，依次定位到00000000000000368769.index的元数据物理位置和00000000000000368769.log的物理偏移地址,然后再通过00000000000000368769.log顺序查找直到offset=368776为止。

如何保证消息消费的有序性呢？
举个例子，比如说生产者生产了25个订单，订单假设分为创建-提交-付款-发货4个步骤，那么消费者在消费的时候按照0到100这个从小到大的顺序消费，那么kafka如何保证这种有序性呢？

难度就在于，生产者生产出0到100这100条数据之后，通过一定的分组策略存储到broker的partition中的时候，
比如0到10这10条消息被存到了这个partition中，10到20这10条消息被存到了那个partition中，这样的话，消息在分组存到partition中的时候就已经被分组策略搞得无序了。

那么能否做到消费者在消费消息的时候全局有序呢？遇到这个问题，我们可以回答，在大多数情况下是做不到全局有序的。但在某些情况下是可以做到的。比如我的partition只有一个，这种情况下是可以全局有序的。

那么可能有人又有疑问了，只有一个partition的话，哪里来的分布式呢？哪里来的负载均衡呢？所以说，全局有序是一个伪命题！让订单全局有序根本没有办法在kafka内部做到。但是我们只能保证当前这个partition内部消息消费的有序性。

结论：一个partition中的数据是有序的吗？回答：间隔有序，不连续。

针对一个topic里面的数据，只能做到partition内部有序，不能做到全局有序。特别是加入消费者的场景后，如何保证消费者的消费的消息的全局有序性，

这是一个伪命题，只有在一种情况下才能保证消费的消息的全局有序性，那就是只有一个partition！

kafka的消息结构

• 8 byte
  offset在parition(分区)内的每条消息都有一个有序的id号，这个id号被称为偏移(offset),它可以唯一确定每条消息在parition(分区)内的位置。即offset表示partiion的第多少message
• 4 byte message sizemessage大小
• 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表示实际消息数据。