一、入门

1、简介

Kafka 是linkedin 公司用于日志处理的分布式消息队列，同时支持离线和在线日志处理。kafka 对消息保存时根据Topic进行归类，发送消息者成为Producer,消息接受者成为Consumer,此外kafka 集群有多个kafka 实例组成，每个实例(server)称为broker。无论是kafka集群，还是producer和consumer 都依赖于zookeeper 来保证系统可用性，为集群保存一些meta 信息。

我们先来看下几个消息传递系统的术语：

在较高的层次上看，生产者通过网络发送消息到Kafka集群，Kafka集群将这些消息提供给消费者，如下图：

客户端与服务器之间的通信通过一个简单的、高性能的、语言无关的TCP protocol. Kafka有Java客户端，但这客户端在很多语言many languages也是有效的。

Kafka的整体架构如图所示。因为Kafka内在就是分布式的，一个Kafka集群通常包括多个代理。为了均衡负载，将话题分成多个分区，每个代理存储一或多个分区。多个生产者和消费者能够同时生产和获取消息。

2、主题（Topics）、日志（Logs）

一个Topic可以认为是一类消息，每个topic 将被分成多个partition(区),每个partition 在存储层面是append log 文件。任何发布到此partition 的消息都会被直接追加到log 文件的尾部，每条消息在文件中的位置称为offset（偏移量），offset 为一个long型数字，它是唯一标记一条消息。kafka 并没有提供其他额外的索引机制来存储offset，因为在kafka 中几乎不允许对消息进行“随机读写”。

一个主题就是消息的类别或名称。对每个主题，Kafka集群都管理着一个被分区的日志，如下：

每个分区就是一个提交日志：每个分区上保存着不断被追加的消息，这些消息是有序的且顺序不可改变；分区上的每个消息都被分配了一个序列号offset，offset唯一标识了分区上的消息。

在kafka 中，即使消息被消费,消息仍然不会被立即删除。日志文件将会根据broker 中的配置要求,保留一定的时间之后删除;比如log 文件保留2 天,那么两天后,文件会被清除,无论其中的消息是否被消费。kafka 通过这种简单的手段,来释放磁盘空间,以及减少消息消费之后对文件内容改动的磁盘IO 开支。

对于consumer 而言,它需要保存消费消息的offset,对于offset的保存和使用, 由consumer 来控制; 当consumer 正常消费消息时,offset 将会"线性"的向前驱动,即消息将依次顺序被消费。事实上consumer 可以使用任意顺序消费消息,它只需要将offset 重置为任意值。(offset 将会保存在zookeeper 中,参见下文)

kafka集群几乎不需要维护任何consumer和producer 状态信息,这些信息由zookeeper 保存;因此producer和consumer 的客户端实现非常轻量级,它们可以随意离开,而不会对集群造成额外的影响。partitions的设计目的有多个。最根本原因是kafka基于文件存储。通过分区,可以将日志内容分散到多个server 上,来避免文件尺寸达到单机磁盘的上限,每个partiton都会被当前server(kafka实例)保存;可以将一个topic 切分多任意多个partitions来保存消息。此外越多的partitions 意味着可以容纳更多的consumer,有效提升并发消费的能力。(具体原理参见下文)。这些特性表明，Kafka的消费者是非常廉价的，一个消费者的创建、销毁不会对集群或其他消费者产生多大的影响。

对日志进行分区有几个目的：

3、分布式（Distribution）

一个Topic 的多个partitions,被分布在kafka 集群中的多个server 上;每个server(kafka 实例)负责partitions中消息的读写操作;此外kafka 还可以配置partitions 需要备份的个数(replicas),每个partition 将会被备份到多台机器上,以提高可用性。

基于replicated（冗余） 方案,那么就意味着需要对多个备份进行调度;每个partition都有一个机器为"leader";零个或多个机器作为follower。leader 负责所有的读写操作,follower执行leader的指令。如果leader 失效,那么将会有其他follower 来接管(成为新的leader);follower只是单调的和leader 跟进,同步消息即可。由此可见作为leader 的server 承载了全部的请求压力,因此从集群的整体考虑,有多少个partitions就意味着有多少个"leader",kafka会将"leader"均衡的分散在每个实例上,来确保整体的性能稳定。

4、生产者（Producers）

Producer 将消息发布到指定的Topic中,同时Producer 也能决

定将此消息归属于哪个partition;这可以通过简单的循环的方式来实现，或者使用一些分区方法（比如根据消息的key来分区）

5、消费者（Consumers）

传统的消息传递有两种方式： 队列方式（queuing）、发布-订阅（publish-subscribe）方式.

队列方式：一组消费者从机器上读消息，每个消息只传递给这组消费者中的一个。

分布-订阅方式：消息被广播到所有的消费者。Kafka提供了一个消费组（consumer group）的说法来概括这两种方式。

消费者都属于一个消费组;反过来说,每个消费组中可以有多个消费者。发送到Topic的消息,只会被订阅此Topic的每个消费组中的一个消费组消费。如果所有的消费者都具有相同的消费组,这种情况和queue模式很像;消息将会在consumers之间负载均衡。如果所有的consumer 都具有不同的group,那这就是"发布-订阅"，消息将会广播给所有的消费者。

在kafka 中,一个partition 中的消息只会被group 中的一个consumer 消费;每个group 中consumer 消息消费互相独立;我们可以认为一个group 是一个"订阅"者,一个Topic 中的每个partions,只会被一个"订阅者"中的一个consumer消费,不过一个consumer 可以消费多个partitions 中的消息。kafka只能保证一个partition中的消息被某个consumer 消费时,消息是顺序的。事实上,从Topic 角度来说,消息仍不是有序的。kafka 的设计原理决定,对于一个topic,同一个group 中不能有多于partitions 个数的consumer 同时消费,否则将意味着某些consumer 将无法得到消息。

生产者发送的消息按照它们发送的顺序追加到主题

消费者看到消息的顺序就是消息在日志中存储的顺序

由此可以得到 Kafka与传统消息系统相比，有以下不同：

原文出处：http://blog.csdn.net/tanggao1314/article/details/51927081