为了便于说明问题,假设这里只有一个单节点的伪分布式Kafka集群。在这个Kafka broker实例的$KAFKA_HOME/config/server.properties中配置 log.dirs=/tmp/kafka-logs，以此来设置 Kafka 消息文件存储目录。并通过命令:
|
1 |
$KAFKA_HOME/bin/kafka-topics.sh --create --zookeeper localhost:2181 --partitions 4 --topic topic_test --replication-factor 1 |
创建一个 topic:topic_test，partition的数量配置为4。接下来可以在 /tmp/kafka-logs 目录中可以看到生成了 4 个partition目录：
|
1 2 3 4 |
drwxr-xr-x 2 root root 4096 Apr 10 16:10 topic_test-0 drwxr-xr-x 2 root root 4096 Apr 10 16:10 topic_test-1 drwxr-xr-x 2 root root 4096 Apr 10 16:10 topic_test-2 drwxr-xr-x 2 root root 4096 Apr 10 16:10 topic_test-3 |
在Kafka文件存储中，同一个topic下有多个不同的partition，每个partiton为一个目录，partition的名称规则为topic名称+有序序号，第一个序号从0开始计，最大的序号为partition数量减1，类似数组的索引, partition是实际物理上的概念，而topic是逻辑上的概念,更多表象是一个消息的类别，当然，partition还可以细分为segment(文件)，一个partition物理上由多个segment组成.
为什么不能以partition 作为存储单位?
如果就以partition 为最小存储单位，可以想象，当Kafka producer不断发送消息，必然会引起partition文件的无限扩张，将对消息文件的维护以及已消费的消息的清理带来严重的影响，新数据是在文件尾部追加的，不论文件数据文件有多大，这个操作永远都是 O(1)的查找，再者，查找某个offset的Message是顺序查找的。因此，如果数据文件很大的话，查找的效率就低. 因此，需以segment 为单位将partition进一步细分。每个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填充，如下：
|
1 2 3 4 5 6 7 8 9 |
00000000000000000000.index 00000000000000000000.log 00000000000000000000.timeindex 00000000000000170410.index 00000000000000170410.log 00000000000000170410.timeindex 00000000000000239430.index 00000000000000239430.log 00000000000000239430.timeindex |
以上面的segment文件为例，展示出segment中的00000000000000170410.index文件和00000000000000170410.log文件是存在对应关系的，.index索引文件存储大量的元数据，.log数据文件存储大量的消息，索引文件中的元数据指向对应数据文件中message的物理偏移地址(也就是实际的偏移地址，因为会涉及到segment文件清理)。其中以.index索引文件中的元数据[3, 348]为例，在.log数据文件表示第3个消息，该消息的物理偏移地址为348。
如何保证消息消费的有序性呢？
举个例子，比如说生产者生产了25个订单，订单假设分为创建-提交-付款-发货4个步骤，那么消费者在消费的时候按照0到100这个从小到大的顺序消费，那么kafka如何保证这种有序性呢？
难度就在于，生产者生产出0到100这100条数据之后，通过一定的分组策略存储到broker的partition中的时候，比如0到10这10条消息被存到了这个partition中，10到20这10条消息被存到了那个partition中，这样的话，消息在分组存到partition中的时候就已经被分组策略搞得无序了。
那么能否做到消费者在消费消息的时候全局有序呢？遇到这个问题，我们可以回答，在大多数情况下是做不到全局有序的。但在某些情况下是可以做到的。比如我的partition只有一个，这种情况下是可以全局有序的。
那么可能有人又有疑问了，只有一个partition的话，哪里来的分布式呢？哪里来的负载均衡呢？所以说，全局有序是一个伪命题！让订单全局有序根本没有办法在kafka内部做到。但是我们只能保证当前这个partition内部消息消费的有序性。
针对一个topic里面的数据，只能做到partition内部有序，不能做到全局有序。
当然不使用一个partition我们可以从代码层面解决.
如何从partition中通过offset查找message?
以上图为例，读取offset=170418的消息，首先查找segment文件，其中00000000000000000000.index为最开始的文件，第二个文件为00000000000000170410.index(起始偏移为170410)，而第三个文件为00000000000000239430.index（起始偏移为239430），所以这个offset=170418就落到了第二个文件之中。其他后续文件可以依次类推，以其实偏移量命名并排列这些文件，然后根据二分查找法就可以快速定位到具体文件位置。其次根据00000000000000170410.index文件中的[8,1325]定位到00000000000000170410.log文件中的1325的位置进行读取。
怎么知道何时读完本条消息，否则就读到下一条消息的内容了？
这个问题就得引出kafka的消息结构，如下图所示：
消息都具有固定的物理结构，包括：offset（8 Bytes）、消息体的大小（4 Bytes）、crc32（4 Bytes）、magic（1 Byte）、attributes（1 Byte）、key length（4 Bytes）、key（K Bytes）、payload(N Bytes)等等字段，可以确定一条消息的大小，即读取到哪里截止。
总结,offset的查找方机制是建立在offset是有序的,索引文件被映射到内存中，所以查找的速度还是很快的。
另外,Kafka的Message存储采用了分区(partition)，Segment和index这几个手段来达到了高效性。
Views: 589