Kafka是linkedin于2010年12月份开源的消息系统，它主要用于处理活跃的流式数据。活跃的流式数据在web网站应用中非常常见，这些数据包括网站的pv、用户访问了什么内容，搜索了什么内容等。这些数据通常以日志的形式记录下来，然后每隔一段时间进行一次统计处理。传统的日志分析系统提供了一种离线处理日志信息的可扩展方案，但若要进行实时处理，通常会有较大延迟。而现有的消（队列）系统能够很好的处理实时或者近似实时的应用，但未处理的数据通常不会写到磁盘上，这对于Hadoop之类（一小时或者一天只处理一部分数据）的离线应用而言，可能存在问题。Kafka正是为了解决以上问题而设计的，它能够很好地离线和在线应用。
Kafka的特性如下：
1) 通过在O(1)的磁盘数据结构上提供消息持久化，对于即使数以TB的消息存储也能够保持长时间的稳定性能。
2) 高可用：Kafka通过消息副本的方式（数据复制）来确保消息的持久性与更高的可用性。
3) 高吞吐：在商用机器上可以提供每秒数十万条的消息
4) 支持在Kafaka服务器集群上进行messages分片，并在把messages在消费集群的机器上分配的同时维护每个分片的顺序信息。
5) 支持将数据并行的加载到Hadoop中。
在Kafka构架中，生产者往代理中发布数据时，采用Push(推)的方式，消费者从代理中取数据时采用Pull（拉）的方式。
在对消息进行存储和缓存时，Kafka严重地依赖于文件系统。大家普遍认为“磁盘很慢”，因而人们都对持久化结（persistent structure）构能够提供说得过去的性能抱有怀疑态度。实际上，同人们的期望值相比，磁盘可以说是既很慢又很快，这取决于磁盘的使用方式。设计的很好的磁盘结构往往可以和网络一样快。
磁盘性能方面最关键的一个事实是，在过去的十几年中，硬盘的吞吐量正在变得和磁盘寻道时间严重不一致了。结果，在一个由6个7200rpm的SATA硬盘组成的RAID-5磁盘阵列上，线性写入（linear write）的速度大约是300MB/秒，但随即写入却只有50k/秒，其中的差别接近10000倍。线性读取和写入是所有使用模式中最具可预计性的一种方式，因而操作系统采用预读（read-ahead）和后写（write-behind）技术对磁盘读写进行探测并优化后效果也不错。预读就是提前将一个比较大的磁盘块中内容读入内存，后写是将一些较小的逻辑写入操作合并起来组成比较大的物理写入操作。关于这个问题更深入的讨论请参考这篇文章 ACM Queue article ；实际上他们发现，在某些情况下，顺序磁盘访问能够比随即内存访问还要快！
为了抵消这种性能上的波动，现代操作系变得越来越积极地将主内存用作磁盘缓存。所有现代的操作系统都会乐于将 所有 空闲内存转做磁盘缓存，即时在需要回收这些内存的情况下会付出一些性能方面的代价。所有的磁盘读写操作都需要经过这个统一的缓存。想要舍弃这个特性都不太容易，除非使用直接I/O。因此，对于一个进程而言，即使它在进程内的缓存中保存了一份数据，这份数据也可能在OS的页面缓存（pagecache）中有重复的一份，结构就成了一份数据保存了两次。
更进一步讲，我们是在JVM的基础之上开发的系统，只要是了解过一些Java中内存使用方法的人都知道这两点：
Java对象的内存开销（overhead）非常大，往往是对象中存储的数据所占内存的两倍（或更糟）。
Java中的内存垃圾回收会随着堆内数据不断增长而变得越来越不明确，回收所花费的代价也会越来越大。
由于这些因素，使用文件系统并依赖于页面缓存要优于自己在内存中维护一个缓存或者什么别的结构 —— 通过对所有空闲内存自动拥有访问权，我们将可用的缓存大小翻了一倍，然后通过保存压缩后的字节结构而不是单个的对象，缓存可用大小接着可能又翻了一倍。这么做下来，在GC性能不受损失的情况下，我们可用在一台有32G内存的机器上获得高达28到30G的缓存。而且，这种缓存即使在服务重启之后仍然会保存有效，不像进程内缓存，进程重启后还需要在内存中进行缓存重建（10G的缓存重建时间可能需要花10分钟），否则就需要以一个全空的缓存开始运行（这么做它的初始性能会非常糟糕）。这还大大简化了代码，因为对缓存和文件系统之间的一致性进行维护的所有逻辑现在都是在OS中实现的，这事OS做起来要比我们在进程中做那种一次性的缓存更加高效，准确性也更高。如果你使用磁盘的方式更偏向于线性读取操作，那么随着每次磁盘读取操作， 预读就会 非常高效使用后面准能用得着的数据填充缓存。
这就让人联想到一个非常简单的设计方案：不是要在内存中保存尽可能多的数据并在需要时将这些数据刷新（flush）到文件系统，而是我们要做完全相反的事情。所有数据都要立即写入文件系统中持久化的日志中但不进行刷新数据的任何调用。实际中这么做意味着，数据被传输到OS内核的页面缓存中了，OS随后会将这些数据刷新到磁盘的。此外我们添加了一条基于配置的刷新策略，允许用户对把数据刷新到物理磁盘的频率进行控制（每当接收到N条消息或者每过M秒），从而可以为系统硬件崩溃时“处于危险之中”的数据在量上加个上限。
这种以页面缓存为中心的设计风格在一篇讲解 Varnish的设计思想的 文章 中有详细的描述（文风略带有助于身心健康的傲气）。
消息系统元数据的持久化数据结构往往采用BTree。BTree是目前最通用的数据结构，在消息系统中它可以用来广泛支持多种不同的事务性或非事务性语义。它的确也带来了一个非常高的处理开销，Btree运算的时间复杂度为O(log N)。一般O(log N)被认为基本上等于常量时长，但对于磁盘操作来讲，情况就不同了。磁盘寻道时间一次要花10ms的时间，而且每个磁盘同时只能进行一个寻道操作，因而其并行程度很有限。因此，即使少量的磁盘寻道操作也会造成非常大的时间开销。因为存储系统混合了高速缓存操作和真正的物理磁盘操作，所以树型结构（tree structure）可观察到的性能往往是超线性的（superlinear）。更进一步讲，BTrees需要一种非常复杂的页面级或行级锁定机制才能避免在每次操作时锁定一整颗树。实现这种机制就要为行级锁定付出非常高昂的代价，否则就必须对所有的读取操作进行串行化（serialize）。因为对磁盘寻道操作的高度依赖，就不太可能高效地从驱动器密度（drive density）的提高中获得改善，因而就不得不使用容量较小(< 100GB)转速较高的SAS驱动去，以 维持一种比较合理的 数据与寻道容量之比。
直觉上讲，持久化队列可以按照通常的日志解决方案的样子构建，只是简单的文件读取和简单地向文件中添加内容。虽然这种结果必然无法支持BTree实现中的丰富语义，但有个优势之处在于其所有的操作的复杂度都是O(1)，读取操作并不需要阻止写入操作，而且反之亦然。这样做显然有性能优势，因为性能完全同数据大小之间脱离了关系 —— 一个服务器现在就能利用大量的廉价、低转速、容量超过1TB的SATA驱动器。虽然这些驱动器寻道操作的性能很低，但这些驱动器在大量数据读写的情况下性能还凑和，而只需1/3的价格就能获得3倍的容量。能够存取到几乎无限大的磁盘空间而无须付出性能代价意味着，我们可以提供一些消息系统中并不常见的功能。例如，在Kafka中，消息在使用完后并没有立即删除，而是会将这些消息保存相当长的一段时间（比方说一周）。
Kafka的集群有多个Broker服务器组成，每个类型的消息被定义为topic，同一topic内部的消息按照一定的key和算法被分区(partition)存储在不同的Broker上，消息生产者producer和消费者consumer可以在多个Broker上生产/消费topic。
KafKa的构架图如下：
Kafka在consumer和broker之间有一个内建的负载均衡器。要达到这种配合，每一个broker和consumer都要在Zookeeper中注册它的状态并且保存它的元数据。 当这里有一个broker和consumer的改变的时候，Zookeeper的观察者将通知每一个consumer。 接着consumer读取所有当前关于相关的broker和consumer的信息，并决定应该消费来自拿个broker的数据。
这种集群感知的消费平衡有一些优点：
l 它允许在consumer进程排序方面更好的语义支持（从此所有的对于一个特定分片的更新将作为一个单独的流被按顺序处理）
l 它也强制在集群中公平负载这样每一个broker都将被用来消费
l 最后，因为进程之间不会协调除了当一个新的broker或者consumer出现的时候，它可以更加的有效。不是在每一个请求的时候在分片上加锁和解锁（这可能比想象中的还耗费资源），我们仅仅是将一个分片锁定给一个特定的consumer进程直到网络拓扑发生变化。这使得用一个在元数据中懒惰的更新换取了更好的性能。
kafka是显式分布式架构，producer、broker（Kafka）和consumer都可以有多个。Kafka的作用类似于缓存，即活跃的数据和离线处理系统之间的缓存。几个基本概念：
（1）message（消息）是通信的基本单位，每个producer可以向一个topic（主题）发布一些消息。如果consumer订阅了这个主题，那么新发布的消息就会广播给这些consumer。
（2）Kafka是显式分布式的，多个producer、consumer和broker可以运行在一个大的集群上，作为一个逻辑整体对外提供服务。对于consumer，多个consumer可以组成一个group，这个message只能传输给某个group中的某一个consumer.
