为什么Kafka可以高效快速的存储

总结：

1. 顺序写入

因为硬盘是机械结构，每次读写都会寻址->写入，其中寻址是一个“机械动作”，它是最耗时的。所以硬盘最“讨厌”随机I/O，最喜欢顺序I/O。
为了提高读写硬盘的速度，Kafka就是使用顺序I/O。如果一个topic建立多个分区那么每个parathion都是一个文文件，收到消息后Kafka会把数据插入到文件末尾。

2. Memory Mapped Files（内存映射文件）

64位操作系统中一般可以表示20G的数据文件，它的工作原理是直接利用操作系统的Page来实现文件到物理内存的直接映射。完成映射之后你对物理内存的操作会被同步到硬盘上

3. 高性能的日志存储

有两大法宝：分段、索引

• 数据文件的分段
  Kafka解决查询效率的手段之一是将数据文件分段。
  比如有100条Message，它们的offset是从0到99。假设将数据文件分成5段，第一段为0-19，第二段为20-39，以此类推，每段放在一个单独的数据文件里面，数据文件以该段中最小的offset命名。
  这样在查找指定offset的Message的时候，用二分查找就可以定位到该Message在哪个段中。

• 为数据文件创建索引
  数据文件分段使得可以在一个较小的数据文件中查找对应offset的Message了，但是这依然需要顺序扫描才能找到对应offset的Message。为了进一步提高查找的效率，Kafka为每个分段后的数据文件建立了索引文件，文件名与数据文件的名字是一样的，只是文件扩展名为.index。

  相对offset：  
      因为数据文件分段以后，每个数据文件的起始offset不为0，相对offset表示这条Message相对于其所属数据文件中最小的offset的大小。 
      举例，分段后的一个数据文件的offset是从20开始，那么offset为25的Message在index文件中的相对offset就是25-20 = 5。存储相对offset可以减小索引文件占用的空间。
  position：  
      表示该条Message在数据文件中的绝对位置。只要打开文件并移动文件指针到这个position就可以读取对应的Message了。
  复制代码

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

  小结：

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

  partition是分段的，每个段叫LogSegment，包括了一个数据文件和一个索引文件
  下图是某个partition目录下的文件：
  可以看到，这个partition有4个LogSegment。

  简单介绍一下如何查找Message的：
  如下，假设有1000条消息，每个LogSegment大小为100，下面展现了900-1000的index和log：

  比如：要查找绝对offset为911的Message：

  1. 用二分查找确定它是在哪个LogSegment中
  2. 打开这个Segment的index文件，也是用二分法查找 (911-900) =11这个索引或者小于11最近的索引在这里我们找到了索引是[10,1367]  
  3. 打开log文件，从位置为1367的那个地方开始顺序扫描直到找到offset为911的那条Message。
  复制代码

  这套机制是建立在offset是有序的。索引文件被映射到内存中，所以查找的速度还是很快的。

一句话，Kafka的Message存储采用了分区(Partition)，分段(LogSegment)和稀疏索引(SparseIndex)这几个手段来达到了高效性。

文章转载自：Kafka的Log存储解析