Kafka文档阅读笔记（一）

老大让我用Kafka+Spark Streaming搭建简单的数据处理平台，以下记录我在学习中的一些要点。目前我的整理基于Kafka 0.8.22 documentation的文档。

入门指南

overview

Kafka中有几个概念很重要：partition、topic、producer、consumer。partition要深入了解，因为它和msg order guarantee， fault tolerace关系很大！

简介

Kafka is a distributed, partitioned, replicated commit log service.像官方介绍的那样，Kafka是分布式、分区、可复制的提交日志服务。它采用独特的设计来实现消息服务系统。

回顾一些术语

• topics...maintains feeds of messages in categories（维护目录中的消息源）

• producers...发布消息到Kafkatopic的进程

• consumers...订阅topic中消息与处理源（feeds）中发布过消息的进程

• broker...运行一个或多个服务的Kafka集群

概念图见下：

clients与servers端使用TCP协议通信

Topics&Logs

Topic是目录或订阅源的名字，用来接受发布过的消息。对于每个topic，Kafka维护一个分区日志，看起来如下：

每个分区有序，不断附加不可变的消息，称之为a commit log，每个分区中的消息被分配连续的数字称之为offset，每个分区中消息的offset不同

Kafka集群维护所有已经发布的消息。当然我们可以配置时间来决定集群维护消息的时间长短。在可用时间内消息都可以被消费者消费，超过这个时间消息会被删除来节省时间。Kafka's performance is effectively constant with respect to data size so retaining lots of data is not a problem：Kafka的性能是一个相对高效常亮，不管数据量多少，所以它维护大量的数据不是问题。

每个消费者维护一个元数据：它指消费者读取的消息在日志中的位置，即offset。它由consumer控制。随着读取消息，offset会线性递增。consumer可以按照任意顺序消费消息。 For example a consumer can reset to an older offset to reprocess.

以上特性的组合使得consumer的代价很小。consumer数量可以增加或减少而对整个集群影响很小。例如在不影响consumers和消费内容的情况下从topic尾部内容读取消息。

分区 && Distribution

partitions意义重大：

• First, they allow the log to scale beyond a size that will fit on a single server. Each individual partition must fit on the servers that host it, but a topic may have many partitions so it can handle an arbitrary amount of data.

• Second they act as the unit of parallelism—more on that in a bit.

Each partition is replicated across a configurable number of servers for fault tolerance.每个分区（内容）都是课重复的，需要在承载分区的服务器上配置。这是实现容错的一种方案。

每个分区都有1个server作为leader，0/多个server作为followers
leader处理分区的读写请求，followers服从leader，复制leader的操作。
若leader故障，自动选取followers为新的leader

Each server acts as a leader for some of its partitions and a follower for others so load is well balanced within the cluster.

Producer

选择发送什么消息给哪个topic的哪个分区。[从这个角度看producer角色也很厉害]
This can be done in a round-robin fashion simply to balance load or it can be done according to some semantic partition function (say based on some key in the message). More on the use of partitioning in a second.

Consumers

传统上有2中处理消息的方法：队列和发布/订阅机制。

• 队列模式下，消费者池从一台服务器上读取消息，并且每条消息只能发送给消费者池中的一个消费者

• 发布/订阅模式下，消息广播到所有的消费者。

consumer group，给一组consumers打标签，标签名即组名

Consumers label themselves with a consumer group name, and each message published to a topic is delivered to one consumer instance within each subscribing consumer group. Consumer instances can be in separate processes or on separate machines.

结合这张图理解

大致意思是：每个发送到topic的消息都会被发送给订阅这个topic的consumer group中的一个consumer。consumer实例可以在不同的进程或机器中。

当所有consumers属于一个group，这时的发布/订阅模式等同于队列模式。

当所有的consumer都属于不同的group时，这就是典型的发布/订阅模式，topic的消息发送给所有的consumer。

更一般的情况是每个topic有少量的groups，每个group都是topic的“逻辑订阅者”。此时每个group有多个consumer实现扩展性和容错。这里订阅者是sonsumer集群而不是单个进程。这里依然符合发布/订阅语义。

相比传统的消息系统，Kafka有健壮的顺序保证。

Kafka提出了分区的设计，将不同topics下的不同分区的消息分配给sonsumer group下的consumers，确保每个分区都能够被唯一一个consumer按消息发送的顺序处理消息数据。根据情况设计多个分区实现负载均衡。note：consumer数量不能超过partition数量

Kafka只保证每个分区内的顺序，不同的分区间无法保证消息的顺序性。如果你需要所有的消息都按照顺序，那么只能设置一个分区，一个consumer实例。这时注意负载均衡和扩展性就无法保证了

guarantee

• order

  • 对于1个分区，早发送到分区的offset<后发送到分区的offset

  • 对于存放在log中的内容按照存储的先后顺序读取

• 如果replication factor为N，最多允许N-1台server故障

Use Cases（使用案例）

• Website Activity Tracking（网站活动跟踪）

• Metrics

• Log Aggregation（日志聚合）

• Stream Processing

原文连接