kafka关键特
可伸缩架构
高吞吐量
consumer自动负载均衡
支持集群多副本
而本博客是一个kafka文件系统深入过程。
存储结构
目的：提高磁盘利用率和消息处理性能。
1.在kafka文件系统中，同一个topic下有多个不同partition，每个partition创建一个目录。即topic下有分区的子目录。
2.每个partion相当于一个巨型文件被平均分配到多个大小相等的多个segment(段)文件中。但每个段segment file消息数量不一定相等，这种特性方便old segment file快速被删除。即分区目录下log文件大小一样。而且一个分区段文件（log文件）对应一个索引文件（index文件）
3.每个partiton只需要支持顺序读写就行了，segment文件生命周期由服务端配置参数决定。
4.index为稀疏索引结构，并不存储每条记录的元数据信息。
如何在partition中快速定位segment file
- 同一个topic下有不同分区，每个分区下面会划分为多个(段)文件，只有一个当前文件在写（一个分区对应一个消费者），其他文件只读。当写满一个文件（写满的意思是达到设定值）则切换文件，新建一个当前文件用来写，老的当前文件切换为只读。文件的命名以起始偏移量来命名。删除文件时，使用了写时复制技术。
- 当消费者要拉取某个消息起始偏移量位置的数据变的相当简单，只要根据传上来的offset分查找文件列表，定位到具体文件，然后根据索引文件分搜索，定位到index中的offset，读取log文件的偏移量，定位到log，即可开始传输数据。
高效文件系统特点
1．一个大文件分成多个小文件段。
2．多个小文件段，容易定时清除或删除已经消费完文件，减少磁盘占用
3．index，log全部映射到memory直接操作，使用零拷贝加页缓存技术，避免segment file被交换到磁盘增加IO操作次数。
4．根据索引元数据信息，可以确定consumer每次批量拉取最大msg chunk数量。
5．索引文件元数据存储用的是相对前个segment file的 offset存储，节省空间小
假设你意气风发，要开发新一代的互联网应用，以期在互联网事业中一展宏图。借助云计算，很容易开发出如下原型系统：
- Web应用：部署在云服务器上，为个人电脑或者移动用户提供的访问体验。
- SQL数据库：为Web应用提供数据持久化以及数据查询。
这套架构简洁而高效，很快便能够部署到百度云等云计算平台，以便快速推向市场。互联网不就是讲究小步快跑嘛！好景不长。随着用户的迅速增长，所有的访问都直接通过SQL数据库使得它不堪重负，不得不加上缓存服务以降低SQL数据库的荷载；为了理解用户行为，开始收集日志并保存到Hadoop上离线处理，同时把日志放在全文检索系统中以便快速定位问题；由于需要给投资方看业务状况，也需要把数据汇总到数据仓库中以便提供交互式报表。此时的系统的架构已经盘根错节了，考虑将来还会加入实时模块以及外部数据交互，真是痛并快乐着……这时候，应该跑慢一些，让灵魂跟上来。本质上，这是一个数据集成问题。没有任何一个系统能够解决所有的事情，所以业务数据根据不同用途存而放在不同的系统，比如归档、分析、搜索、缓存等。数据冗余本身没有任何问题，但是不同系统之间像意大利面条一样复杂的数据同步却是挑战。这时候就轮到Kafka出场了。Kafka可以让合适的数据以合适的形式出现在合适的地方。Kafka的做法是提供消息队列，让生产者单往队列的末尾添加数据，让多个消费者从队列里面依次读取数据然后自行处理。之前连接的复杂度是O(N^2)，而现在降低到O(N)，扩展起来方便多了：在Kafka的帮助下，你的互联网应用终于能够支撑飞速增长的业务，成为下一个BAT指日可待。以上故事说明了Kafka主要用途是数据集成，或者说是流数据集成，以Pub/Sub形式的消息总线形式提供。但是，Kafka不仅仅是一套传统的消息总线，本质上Kafka是分布式的流数据平台，因为以下特性而著名：- 提供Pub/Sub方式的海量消息处理。
- 以高容错的方式存储海量数据流。
- 保证数据流的顺序。