Kafka官方文档翻译（一）产品概述

流平台的三要素：
1、提供发布/订阅记录流的能力，类似于消息队列；
2、对记录流的存储有容错能力；
3、可以即时处理记录流。
kafka可用于两大类应用：
1、建立实时流数据管道，在系统或应用之间进行可靠传输；
2、建立基于实时流的应用，可以传输或处理数据流。
先知概念：
*kafka运行在单个或多服务器的集群中；
*kafka集群存储的记录（records）流被称为主题（topices）；
*每一条记录持有一个主键（key），一个值（value），一个时戳（timestamp）。
kafka有四个核心API族：
*Porducer API(生产者API)允许应用发布一个流记录到一个或多个kafka主题（topics）
*消费者API（Consumer API)允许应用订阅一个或多个主题并处理主题生产的记录流
*流API（Streams API）允许一个应用扮演一个流处理器，消费从一个或多个主题得到的数据流，并产生一个输出流到若干个输出主题，也就是把输入流转变为输出流。
*连接器API（Connector API）允许构建并运行可重复使用的生产者或消费者，他们可以把kafka的主题连接到已存在的应用或数据系统。比如，一个关系数据库的连接器（扮演消费者或生产者）可以捕获一个数据表的每一个修改（扮演主题）。
一个主题代表了已发布的记录组。主题支持多人订阅，一个主题可以有0个或多个消费订阅它的写入数据。
kafka集群为每一个主题保留了一个分区记录。每个分区都是有序的、包含序列记录集，并不断追加带格式的提交日志。分区中的记录集中，每一条记录都有一个有序唯一的ID号，称之为“偏移量（offset）”。
kafka集群保留了所有已发布的记录集，而不论他们是否被消费掉，保留周期可以配置。比如，如果保留规则是两天，那么当一条可消费记录发布两天后，它将会被删除来释放空间。kafka可以有效的保持数据的固定大小，因而长时间保存数据也不是问题。
事实上，日志中基于单个消费者的元数据只有偏移量和消费者的读写位置。而偏移量也是受消费者控制：通常，一个消费者可能优先线性读取记录集，其实因为读写位置也是受消费者控制的，因而它可以按任意顺序消费记录集。比如一个消费者可以重置偏移量到一个旧的位置然后处理数据，或者向前跳过大部分最近的记录然后消费“现在”这个记录。
从上面的功能我们可以看出，kafka的消费者占用的资源是非常少的，他们可以随时订阅处理记录而不会影响集群或者其他人。你可以用命令行工具“tail“到某个主题而不改变其他消费者的消费动作。
日志分区可以达成几个目的。首先，存放在单服务器中长度固定的日志文件可以被扩展。每个分区个体都要被存储到托管服务器中，而一个主题可能存在于多个分区中，所以它可以处理任意多的数据。其次，他们更多的是扮演了并行单元的角色。
分布式
日志的分区是分布在kafka集群的服务器上面的，每个服务器共享处理分区的数据和请求。每个分区可以备份在可配置数量的服务器中用于容错机制。
每个分区的备份服务器中，有一个扮演leader的角色，其他服务器作为followers。leader处理分区所有的读写请求，而follower备份leader。如果leader运行出错，其中一个follower会自动成为新的leader。一个服务器对某些分区来说是leader，但对其他分区来说是follower，因而集群具有很好的负载平衡。
生产者
生产者把数据发布到他们选择的主题中。生产者负责指定主题中的哪条记录关联到哪个分区。该操作可以在一个循环中完成以达到简单的负载均衡，或者依照某个分区函数完成（比如基于记录的主键）。大部分分区都用第二种方法。
消费者
消费者用消费者组名称来标注他们自己。每一条发布到一个主题的记录都会交付给每个订阅消费者组中的一个消费者实例。消费者实例可以运行在多线程或者多主机中。
如果所有的消费者实例在同一个消费者组中，则所有的记录组会按照消费者实例进行有效的负载均衡。
如果所有的消费者实例在不同的消费者组中，则每一条记录会被广播到所有的消费者进程中。
上图中，一个拥有两台服务器的kafka集群托管了四个分区（P0-P3），并有两个消费者组。消费者组A有两个消费者，消费者组B有四个。
普遍情况下，我们发现主题拥有小量的消费者组，一对多个“逻辑订阅者”。每个组由多个消费者实例组成，便于扩展和容错。而这无非是“发布者-订阅者”结构，只是订阅者是消费者集群而不是单一进程。
kafka实现的消费行为是通过按照消费者实例分割日志中的分区，所以任意时刻，每个实例都是一个“公平共享”分区的独有消费者。消费者组中维持这种成员关系的过程被依照kafka的协议动态处理。如果新的实例们加入到消费者组，他们会接管组中其他成员的部分分区。如果一个实例死亡，他的分区会被再分配给剩余的实例。
kafka只提供一个主题在一个分区（而不是不同分区）中基于记录的全序关系。大部分应用中，每个分区内的排序只需和分区数据的“键值”关系相关就足够了。然而，如果你要求从仅有的一个分区获取一个主题的记录的全序关系，那这意味着一个消费者组中只有一个消费者进程。（因为如前面说的，一个消费者组中，一个分区被一个消费者管理，一个消费者管理多个分区）
承诺
kafka提供以下承诺：
*一个生产者发送给一个特定主题分区的消息，会按发送顺序排列。也就是，如果消息M1和消息M2发送自同一个生产者，而且M1先发，那么在日志中M1比M2出现的更早偏移量更小。
*一个消费者看到的记录集和他们在日志中保存的顺序一致。
*一个主题的备份因子是N，我们可以容忍0到N-1的服务器都出错而不丢失任何提交到日志中的记录。
把kafka用做消息系统
如何把kafka的流概念比做传统的消息系统呢？
传统消息传输有两种模式：消息队列和发布者-订阅者。在一个消息队列中，消费者池从一个服务器读取消息而每条记录会发往消费者之一。在发布者-订阅者中，记录会广播给所有的订阅者。两种模式都有其优点和短板。消息队列的优点是允许你把数据处理分割到多个消费者实例，这些实例可以扩展你的操作过程。不幸的是，队列不能多订阅者同时处理一个进程读到的数据。发布者-订阅者允许你广播数据到多个处理进程，但在每条消息抵达每个订阅者之前无法扩展处理进程。
kafka中消费者组的概念统一了这两种模型。作为消息队列，消费者组允许你分割处理过程到一组进程（消费者组的成员）。作为发布者-消费者，kafka允许你广播消息到多个消费者组。
kafka模型的优点是每个主题都有两方面属性————它可以扩展操作过程也支持多用户订阅————不需要二选一。
kafka也有比传统消息系统更严格的序列性。
维持一个传统消息队列服务中记录保持有序，如果多个消费者要消费队列的消息，那么服务器会按照记录存储的顺序取出他们。然而，虽然服务取出消息是有序的，但是记录分配给消费者是异步的，所以他们到达不同消费者时可能已经乱序。也就是说记录的顺序会在并行执行时丢失。消息系统经常用变通的方法称之为“特殊消费者”，只允许一个进程消费一个队列，但是这就不是并行处理了。
kafka做的更好。通过一个主题中的并行概念————分区，kafka可以保证基于消费者进程池的有序性和负载均衡。这个保证，是通过关联主题的分区和消费者组中的消费者获得，即每一个分区只能被组中确定的一个消费者所消费。通过这么做，我们可以确定这个消费者就是这个分区唯一的读取者，消费数据也是有序的。即使有多个分区被多个消费者实例所消费也可以保持负载均衡。（上文的：只有主分区可以被读写，每个分区都是某个主分区同时是别的记录的从分区）。但是要注意，消费者组里的消费者实例不能多于分区实例。
kafka做为存储系统
有些消息队列把发送消息和处理消息解耦，就好像一个动态消息的存储系统。这是不同于kafka的一个很好的存储系统。
kafka把数据写入磁盘并冗余备份。kafka要求生产者等待从数据写入失败到备份完成等过程的确认消息，并把消息持久化（即使过程中服务器写入失败）。
kafka使用的磁盘结构具有很好的扩展性————kafka对50K或50T的数据都会执行同样的持久化到服务器。
通过认真对待存储的结果和允许客户端控制他们的读取位置，你可以想象kafka是一种用于特殊目的的分布式文件系统，拥有高性能，低延迟的对提交日志的存储，备份和传播。
kafka用做流数据处理
数据流不仅仅是读、写、储存，更重要的是实时处理数据流。
kafka系统中，一个流处理过程从输入主题获取持续的数据流，在这个输入上做一些操作处理，然后生成持续的输出流到输出主题。
举例来说，一个零售商应用持续输入销售和发货的数据流，持续输出订单流并根据订单进行价格调整。
直接用生产者-消费者API可能也可以简单直接的处理这个过程。而面对更复杂的变化，kafka提供了功能完备的Streams API。从此构建应用时，不需要再考虑处理过程中计算流的聚合或者把流拼一起等琐碎的细节。
事实上，这解决了该类型应用面对的最困难问题：处理无序数据，代码修改后重新处理输入数据，进行有状态计算，等等。
流API构建了kafka核心基本单元，提供了：把生产者和消费者API用做输入，使用kafka做有状态存储，用相同的组机制实现流处理实例的容错。