Kafka介绍翻译

原文：http://kafka.apache.org/intro
翻译有误之处，请指正，本人不胜感激

#Kafka介绍
作为一个分布式流处理平台，Kafka能做什么？

我们所见的流处理平台有以下三个特性：

1. 允许你发布或者订阅数据流。 类似一个消息队列或者企业消息系统
2. 允许你存储数据流，能够容错存储
3. 数据流出现时让你进行处理 (实时推送处理)

Kafka的优点有哪些？
他被广泛应用于两方面：

1. 构建实时数据流处理管道，在系统或应用间做可靠数据传输
2. 构建实时流处理应用对数据流进行转换处理

通过以下内容，我们将深入了解Kafka是怎样实现上述应用的

先理解几个概念：

1. Kafka是一个集群在一台或多台服务器上运行
2. Topic–主题. Kafka集群中存储的数据流类别叫做Topic。不同类别有不同的Topic
3. 每一条数据记录键、值和时间戳

Kafka有四块核心的API：

1. Producer API – 生产者API， 应用系统用于发布一种或多种主题数据。
2. Consumer API – 消费者API，应用系统用于订阅一种或多种主题，并对接收到的数据流进行处理
3. Streams API – 流处理API， 通过它，应用系统扮演了流处理器的角色，高效对输入的数据流进行转换处理，然后产生输出流。可以处理一种或多种topic。
4. Connector API – 连接API。 对于在应用或数据系统中已存在的Kafka主题，可重复构建和运行与其联通的生产者和消费者通道。如一个关系型数据库连接器可能可以捕获到表的每一个变化，Connector API在Kafka中扮演了连接器在传统关系型数据库中类似的角色。 (这句有问题)

Kafka中，客户端和服务端的通讯是采用简单、高性能以及与语言无关的TCP协议。这种协议可以向后兼容。我们提供了Kafka Java客户端，也可以使用其他语言来使用客户端。

#Topics and Logs
主题和日志
先深入了解Kafka关于流数据的核心概念–主题。

一个主题是被发布记录的类别名称。Kafka中的主题一般有多个订阅者，换句话说，一个主题写入数据时，可以有个0个、1个或多个消费者来进行订阅(这个主题写入的数据并消费)。

对于每一个主题，Kafka集群维护了一个分区日志，如下图：

每个分区是一个有序的、不可变的记录序列，持续追加到一个结构化的提交日志中。 分区中的每个记录都分配了一个有序的标识，Kafka中叫做偏移量，用于在分区中唯一标识每条记录。

不管记录是否被消费，Kafka集群中会保留所有的记录，使用预先配置的保留时间。例如，如果设置保留时间为2天，当记录被发布后，两天内可以被消费，2天之后将被丢弃。数据大小对Kafka的性能影响甚微，长时间保留数据不会影响到Kafka的性能。

---

事实上，每个消费者在日志中唯一保留的是偏移量或位置。消费者控制偏移量：一般情况下消费者会根据读取记录线性的增加偏移量，实际上，由于位置是消费者自己控制的，他可以读取任意位置。例如，消费者可以重置到老的位置重新处理过去的数据，或跳过最近产生的数据从最新位置开始消费。

Kafka的这些特性意味着消费者是非常廉价的，即他们的连接或断开不会退集群或其他消费者产生什么压力。例如，你可以用命令行工具查看所有的topic内容而不会影响所有已存在的消费者的消费。

日志服务中的分区有多个用途。第一，他允许日志文件在一个单独的服务器上指定合适的大小，每个独立的分区必须适合其所在的服务器，但每个topic可以有多个分区以使其可以处理大量的数据。第二，分区是并行数据处理的单位，而不仅仅是在一个点上。

#Distribution (分发/分布式？)
集群内的服务器进行分区日志的分发，对分区的数据和请求，所有服务器共同来处理。通过配置的副本数量，每个分区会进行复制以保证默认的容错。

每个分区都有一台服务器充当Leader的角色，零或多台服务器充当follwers的角色。leader处理分区所有的读写请求，然后通知followers进行复制。如果leader挂掉，有一个followers会自动的成为新leader (注：kafka使用Zookeeper做分布式管理，Leader的选举可以参考Zookeeper的Leader选举过程). 每个服务器同时充当部分分区的Leader和部分分区的follower角色，以达到负载均衡。

#生产者
生产者发布他们选定的topic数据。针对某个topic，每个生产者有责任指定哪条记录到哪个分区。可以通过简单的轮询策略以达到负载均衡，或通过语义来进行分区(如记录的key)。通过语义来分区可以做更多的关于分区的应用。

#消费者
消费者会给自己贴一个消费者组名的标签，topic的每条记录会投递给消费者组里面的一个消费者实例。消费者实例可以在不同的进程或不同的机器上。

如果所有的消费者在同一个组，所有的记录会在所有的消费者之间做负载分配。

如果所有的消费者在不同的组，每条记录会广播给所有的消费者进行处理。

两台服务器组成的kafka集群拥有四个分区(P0到P3)，对接两个消费者组。组A拥有两个消费者，组B拥有四个消费者。

更常见的是，我们发现topcis拥有较少的消费者组，每个“逻辑订阅”一个。每个组由多个消费者实例组成以提升可扩展行和容错性。发布订阅的语义：集群中的众多消费者进行订阅，而不是一个单一的进程。

kafka中消费的实现是将日志中的分区划分给消费者实例，以便每个实例在任何时候都是"公平共享"分区的独占用户。在组内这种处理关系是通过kafka协议动态维持的。如果有新的消费者实例加入消费者组，他们会接管组内其他成员的部分分区。如果一个实例挂掉，他接管的分区会分发给其他存活的消费者实例。

Kafka的消息只在一个分组内保证有序，而不保证一个topic在不同的分区中有序。每个分区通过分区数据的key来进行排序，对大多数应用来说是满足需求的。然而，如果你需要一个topic所有的记录是有序的，可以通过只有一个分区来实现，换言之，该topic只有一个消费者组。

注：Kafka的消息只在一个分组内有序说明。有一个生产者P和一个消费者C，有两个分区P0、P1。生产者按序产生消息m1、m2、m3、m4。其中m1、m2写入分区P0，m3、m4写入分区P1。消费者C接收消息时，P0分区内，消息m1先于m2接收，P1分区内，消息m3先于m4接收， 但P0和P1分区的消息顺序不能保证，即可能m3先于m2接收。

#Guarantees (担保)
高可用的Kafka提供以下几点的担保：

• 生产者发送到某个特定分区的消息会按发送顺序添加到队列。这就是说，如果一个生产者发送消息M1、M2，如果先发送M1，那相对于M2，M1将会有更小的偏移量，会更早的出现在日志中。
• 消费者会有序的看到记录，按记录在日志中存储的顺序。
• 一个消息有N个副本，允许有N-1个服务器挂掉而不会丢失任何提交的数据。

关于这些担保的更多细节在文档的设计章节中给出。

---

Kafka as a Messaging System
作为消息系统的kafka

和传统的起因消息系统相比，kafka的流是怎样工作的

一般而言，消息有两种模式：队列和发布-订阅。 队列模式中，一组消费者从服务器中获取消息，每条消息被其中一个消费者消费；发布-订阅模式，消息使用广播的方式，推送给所有的消费者。这两种模式均有其优缺点。队列模式的优点在于你可以从众多消费者中分割处理 (大量消息)，这样可以扩展你的应用 (大规模处理数据)。相比于多个订阅者，它的劣势在于只能被某个消费者消费一次。发布-订阅模式允许你推送(广播)消息给多个进程，由于每个消费者均需要处理每一条消息，导致不能(水平)扩展你的应用。

kafka中，消费者组的概念包含了这两种观点 (即queue + publish-subscribe)。和队列模式的相同之处在于，kafka允许你在一组消费者中分割处理 (大量消息)。和发布-订阅模式的相同之处在于，kafka允许你给每一组消费者广播消息。

kafka的优势在于同时拥有队列和发布-订阅两种模式的特性。每个消息，既可以被分割处理(在同一个group中)，也可以同时被广播(在不同的group中)，无需选择其中的一种。

同时，相比于传统的消息系统，(在一个consumer group组中) kafka更好的保证了消息的处理顺序。

传统的队列在服务端保证顺序，同一个队列中，如果多个消费者消费消息，服务端根据存储的顺序来分发消息。然后，尽管服务端是按顺序来分发的， 但消息是异步传递给众多消费者的，所以在不同的消费者中出现无序的情况 (如顺序产生两个消息m1、m2，按序分别推送给消费者c1、c2，结果c2先收到消息m2，c1后收到消息m1)。这意味在并行消费的情况下，记录的顺序已经丢失 (并行消费无法保证消费顺序)。针对这种情况，消息系统提出了独占消费者的概念，即一个队列只允许一个消费者，这导致消息系统丢失了并行处理的能力。

kafka有更好的实现方案。针对并行(处理)的概念，kafka提出了消息分区，在一组消费者中能同时保证顺序和并行处理(做负载均衡)。在一组消费者中，kafka通过指定消费者在某一个分区的topic来实现的，以达到每个分区中每个消息被消费者组中的某一个消费者有序的消费。通过这一点，我们保证消费者唯一有序的读取分区数据。由于有很多分区，这样就在众多消费者中实现了负载均衡。然而，在一个消费者组中，不能有比分区更多的消费者(实例)。(如果有，部分消费者就会出现空闲状态)

作为存储系统的Kafka
Kafka as a Storage System

作为消息存储系统，在消息发送过程中， 任何消息队列均能有效针对消息的发送和消费进行解耦。作为一个优秀的存储系统，kafka有什么不同呢？

kafka写操作将数据写入磁盘并进行容错复制。kafka允许生产者等待应答确认直至数据被完整复制，即使服务器写入失败也会进行等待。

在服务器上，不管是50KB还是50TB的持久化数据，Kafka均采用同样的数据结构进行存储。

作为允许客户端自己控制读取位置的存储结果 (a result of taking storage seriously)，你可以把Kafka当做一种专门为高性能、低延迟提交日志存储、复制、传播的专用分布式文件系统。

Kafka流处理
Kafka for Stream Processing

Kafka不仅仅是读、写、存储数据，还可以进行实时流数据处理。

Kafka流处理器可以处理任何输入主题的持续数据流，针对输入流进行一些处理，并产生持续数据流给输出主题。

例如，一个零售应用可能需要从输入流中获取销售和发货数据，然后输出价格调整后的数据

可以直接通过生产者、消费者API做简单的(流数据)处理。针对更复查的处理，Kafka提供了完成的流处理API。他允许应用做复杂的处理，如处理聚合流或者把流进行聚合。

这种特性有助于解决某些类型的复杂问题，这些类型有以下共性：处理无序的数据，代码更改后的再次处理输入，执行状态计算 等等

流API建立在Kafka核心原语上。在一组流处理应用中，使用生产者和消费者API提供的输入，使用Kafka做状态存储，使用同一组机器做容错处理。

Putting the Pieces Together
功能组合

Kafka把消息、存储、流处理的组合看似无用，但他们其实是Kafka流处理平台必不可少的角色

一个分布式文件系统如HDFS(Hadoop分布式文件系统)能够批量存储静态文件。这类系统能高效存储、处理历史数据。

在你订阅后，一个传统的企业消息系统会把(你订阅后)接收到的消息推送给你处理。应用程序通过这种方式来处理后续产生的消息 (消息系统将消息推给应用的方式)

Kafka结合了上述两种能力 (存储、消息推送处理)，这个它作为一个流处理平台和流数据管道应用的重要组成部分

通过组合存储和低延迟订阅，Kafka流处理平台允许应用以相同的方式处理之前以及后续产生的数据。在历史数据被丢弃前，应用能够一直处理历史数据 。 这个就是流处理的概念，他包括了批量处理以及应用消息驱动。
数据丢弃原因： 1. 存储空间/队列的大小是有限的，新消息的持续产生，导致空间不足，从而丢弃老消息； 2. 老数据存储已超过设置的保存时限。

同样，作为流数据管道，实时订阅的功能使低延时管道成为可能。 而数据存储的功能，使它能可靠的保证关键数据的传输，或集成定期加载的离线数据，or may go down for extended periods of time for maintenance. 流处理能力使它可以在数据到达时进行处理

关于Kafka更多的信息，请查看后续的文档