本文的英文原文来自于kafka官方介绍文档

Kafka-logo

Apache Kafka® 是一个分布式的流平台。具体是指什么？

流平台有三个关键能力：

• 发布和订阅流记录，类似与消息队列或者企业信息系统。

• 持久化流记录，用于故障恢复。

• 及时快速处理流记录。

Kafka主要用于两类的程序应用：

• 在系统与应用之间构建实时可靠的流数据通道

• 建立实时的流应用来转换或处理数据流

为了理解Kafka如何实现上述功能，我们下面深入并且探索Kafka的能力。

首先，下面有一些概念：

• Kafka是运行在一台或者多台服务器的集群，能够包含多个数据中心。

• Kafka集群存储流记录名称为主题（topics）

• 每条记录都是由主键，值，时间戳三部分组成。

Kafka有四个核心API：

四个核心API

• 生产者API用于提供应用发送流记录到一个或多个Kafka主题。

• 消费者API用于提供应用订阅一个或多个主题，并且处理生产到对应主题中的流记录。

• 流API用于提供应用能够进行流处理，消费一个或多个主题的输入流，并且产生输出流至一个或多个输出主题，能够将输入流转换为输出流。

• 连接器API用于构建和运行可复用的生产者或消费者，能够连接到现有的应用程序或者数据系统。例如用于获取传统数据库的某个表的所有变更的连接器。

Kafka用一种简单，高性能，语言无关（language agnostic）的TCP协议来进行客户端与服务器端的沟通。这种协议是版本化的，对于老版本也能够向下兼容。我们提供了Kafka的Java客户端，但是也有其他很多语言的客户端。

主题与日志

我们首先来深入了解Kafka提供的流记录-主题。

我们把发布记录的分类或者聚合称之为主题。主题在Kafka中一般都是多订阅的，就是一个主题会有零个，一个或多个消费者订阅被写入的数据。

每个主题，Kafka集群会维护一个如下图的分块日志：

主题日志分块

每个分块都是顺序，不可变序列的记录，并且持续添加到结构化的提交日志。分块中的记录都会被分配一个序列化id序号称之为偏移量（offset）作为每条记录在分块中的唯一标识。

Kafka集群会根据保留期配置持久化所有发布的记录，无论是否被消费。例如保留策略设置为2天，则一条记录发布的两天内，都是可以被消费的，之后就会被丢弃掉来释放空间。Kafka的数据量存储效率是很高的，所以长期存储数据也没有任何问题。

消费者偏移量情况

实际上，在待消费时唯一的元数据就是消费者在日志中的偏移量位置。偏移量是由消费者控制的：正常情况消费者会将偏移量设置到已读取记录，实际上因为偏移量由消费者控制所以可以按照消费者的意愿消费任意排序的记录。例如消费者可以重置偏移量来重新处理过去已经处理过的数据，或者跳过一些历史记录直接从“现在”开始处理最近的记录。

这些特性的混合意味着Kafka消费者是轻量的，可以简单的加入或者移除而不会对集群或其他消费者产生多少影响。例如，你能够使用命令行工具“查看末尾内容（tail'）”针对任意主题的内容而不需要关心究竟是被哪个消费者消费的。

日志服务的分块有几个目的。首先这样能够扩展而不限于单台服务器。服务器上的独立分块受限于主机情况，但是一个主题可以包含很多个分块，所以可以是很大的数据量。其次能够提高并行计算的效率，相比单个文件而言。

分布式

日志的分块是分布部署在Kafka集群的服务器上，每台服务器会负责自己分块的数据和请求。每个分块都会在指定数量的机器上保存多份达到故障容错性。

每个分块都存在一台服务器作为“leader”主服务器以及0台或多台服务器作为“followers”从服务器。主服务器接受所有的读写请求，从服务器同步复制。当主服务器故障时，从服务器中的某台会自动变为新的主服务器。每台服务器可能都是自己内部某些分块的主服务器以和其他分块的从服务器，从而在集群内部负载均衡。

地理位置复制

Kafka镜像制作（MirrorMaker）为集群提供地理位置复制功能。镜像制作能够将消息复制到多个数据中心或者云端。可以在主动或者被动的备份及恢复的场景。或者在某些场景需要将数据位置靠近使用者，或者支持数据本地化的需求。

生产者

生产者将数据发布至目标主题。生产者负责选择记录分配至主题的具体分块。使用轮询分发形式（round-robin fashion）保证负载均衡，或者基于语意分块函数（例如根据记录中的主键分块）。稍后还会介绍分块的更多用法。

消费者

消费者必须指定消费群组的名称，每个发布至主题的记录都会被投递到每个订阅的消费群组的一个消费者实例。消费者实例可以是一个单独的进程或者单独的服务器。

如果所有的消费者是属于相同的消费群组中，则数据记录能够在所有的消费者实例上均衡的消费。

假如所有的消费实例都属于不同的消费群组，则每个数据记录都会广播至所有的消费者进程。

多集群/多消费者

一个两台服务器的Kafka集群包含4个分块（P0-P3）和两个消费集群。消费集群A包含两个消费者实例，消费集群B包含4个消费者实例。

正常我们的主题会有少量的消费集群，单个都对应每个“逻辑订阅者”。每个集群都由多个消费者实例组成来保证可扩展和容错性。在发布订阅的模式中订阅者是集群一定优于单个进程。

消费方法在Kafka内部的实现，是将日志分块至所有的消费者实例中，所以每个实例在任何时间点中都是一个“公平分配”的独立消费者。群组内的成员关系是使用Kafka协议动态维护。当集群中有新实例加入时会从集群成员中分担部分分块。如果实例无效，则它的分区会分发至还存在的实例上。

Kafka只能保持一个记录分块内的整理排序，一个主题的多个不同分块之间则无法保持。使用主键作为数据分块时的排序依据能够满足大部分的应用程序。如果你需要保证单个主题的所有记录排序受控，则只能有一个分块。每个消费集群也只能有一个消费者进程。

多租户

Kafka支持多租户方案。可以在配置中开启多租户设置，主题能够生产或者消费数据。也能够支持定额操作。管理员能够配置并且强制定额请求数量，从而控制客户端使用的代理资源。更多信息可以查看安全文档。

保障

高等级Kafka提供了下面的保障：

• 生产者发送至指定主题分块的会以发送的顺序附加在尾部。如消息M1M2时同样的生产者发送的，M1先发送，则M1的偏移量较低，而且会比M2更早出现在日志中。

• 消费者实例会以消息存储在日志中的顺序读取。

• 主题分为N个复制集，能够支撑N-1的服务器故障，而不会丢失提交到日志中的任何记录。

Kafka作为消息系统

Kafka的流概念与传统的企业消息系统相比是如何呢？

传统消息服务有两种模型：队列和发布-订阅。在队列中消费者池能够从一台服务器读取数据，单个消费者消费一笔记录。发布订阅模式中消息会广播至所有的消费者。这两种模型都有优缺点。队列的优点是能够将数据处理拆分至不同的消费者实例，能够提高处理能力。但是队列无法存在多消费者，一旦某个消费者消费了数据，这条数据就不存在了。发布订阅模式能够广播数据进行多次处理，但是因为每条数据都会发送给每个订阅者，所以很难提高处理效率。

Kafka中的消费群组覆盖了这两个概念。使用队列时，消费群组可以将处理过程分散到处理者集合（消费群组中的成员）。使用发布订阅时，Kafka能够将消息广播到多个消费群组。

Kafka模型的优势在于每个主题都兼有两种特性，能够很容易的扩展也能够有多个订阅者，能够同时兼容。

Kafka对于消息排序比传统消息系统能提供更强的保障。

传统的队列将记录排序保存在服务器上，当多个消费者从队列消费数据时，服务器按照存储的顺序给回数据。尽管服务器按顺序给回数据，但是投递到消费者是异步的，当到达不同的消费者时，可能就是无序的。这样意味着在并行计算中记录的排序是丢失了。传统消息系统为了解决这个问题使用“独占消费者”的概念，只允许使用单进程来消费队列信息，但是这样就不存在平行计算了。

Kafka做的更好。在主题内部存在称之为分块的并行概念，Kafka能够利用消费者进程池同时保证排序和负载均衡。主题中的分块指定消费群组中的消费者，这样每个分块都是被群组中的单个消费者消费。这样我们就能保证某个消费者是单个分块的唯一读取者，也能够按照顺序来消费。因为分块很多所以能够保证多个消费者实例能够保持负载均衡。切记消费群组中的消费者实例的数量不能多于分块的数量。

Kafka作为存储系统

任何消息队列，只要隔离了信息发布和信息消费，实际上就扮演了过程中消息的存储系统的角色。对于Kafka而言，它是一个很好的存储系统。

写入Kafka的数据会写到磁盘，并且复制提高容错性。Kafka允许生产者等待写入回应，而要等到数据完全复制完成才能算写入完成。这样及时当前服务器写入失败也能够保证存储正常。

Kafka的磁盘结构扩展性也很好，无论服务器上的数据是50KB还是50TB，Kafka都能保持一致的性能表现。

Kafka能够很好的存储信息，并且允许客户端控制读取位置，所以可以认为Kafka是特殊的分布式存储系统，能够提供高性能、低延迟的日志存储，复制集，传播。

关于Kafka提交日志存储和复制设计，可以在这里查看更多。

Kafka作为流处理系统

只是读写和存储流数据是不够的，我们希望能够支持实时的流处理。

Kafka中流处理器的概念就是能够持续从输入主题接收流数据，对输入流进行处理，并且对输出主题产生持续的输出数据流。

例如，零售应用以销售和物流作为输入数据，并且基于输入数据计算后的追加订购与价格调整输出数据流。

当你只是做一些简单的处理可以直接使用生产者和消费者API。但是当你需要处理复杂转换时，Kafka提供了完整集成功能的流API。这样能够构建应用来处理重要的处理来聚合流数据或者关联合并流数据。

这些特性能够帮助解决某些应用面对的复杂问题：处理无序数据，代码变化时重新处理输入数据，实施有状态计算等等。

流API基于Kafka的核心特性构建：使用生产者消费者API用于输入，使用Kafka作为状态存储，使用相同的群组机制用于流处理实例保证高容错性。

集成系统

将消息服务、存储和流处理整合在一起看起来很特别，但实际上这才是Kafka在一个流处理平台中的重要角色。

像HDFS这样的分布式文件系统存储静态文件用于批处理。这样的系统在存储和处理过去的历史数据是很有效的。

传统的企业消息系统允许处理你订阅之后产生的未来信息。这种方式构建的应用能够在未来的消息到达时进行处理。

Kafka整合了上面这些特性，这些特性组合对于Kafka作为平台流处理应用或者和流数据管道是同样重要。

依靠整合存储和低延迟订阅，流处理程序能够使用同样的方式同时处理过去和将来的数据。单个应用程序能够处理历史存储的数据，但是不会在处理完最后一笔记录后结束，会保持运行从而在未来数据到达时继续处理。这是流处理的基本概念，也能够纳入批处理，和消息驱动的应用程序相同。

与流数据管道相似的混合订阅与实时事件，使得Kafka能够应用于低延迟管道。但是可靠存储数据的能力使得Kafka可以用于重要数据的传输或者集成只能暂时加载数据或者需要停机维护的的离线系统。流处理特性使得数据能够在到达时转换。

Kafka提供的保障、APIs、特性可以在这份文档中查看。