python中文文档pythonkafka官⽅⽂档_《Kafka官⽅⽂档》介绍
Apache Kafka™ 是 ⼀个分布式数据流平台. 这意味什么呢?
我们认为⼀个数据流平台有三种能⼒:
它让你发布和订阅数据流. 在这⽅⾯他与消息队列或企业级消息系统很像.
它让你具有很强容灾性的存储数据流.
它让你及时的处理数据流.
那么Kafka适合做什么呢? 它通常被使⽤在两⼤类应⽤中:
搭建可以使数据在系统或应⽤之间流动的实时数据流管道(pipelines)
搭建可以针对流数据实⾏实时转换或作出相应反应的数据流应⽤
为了了解Kafka具体如何实现这些功能, 我们来从底层开始，探索⼀下Kafka的功能。 ⾸先讲⼏个概念:
Kafka是作为集，运⾏在⼀台或多台服务器上的.
Kafka集⽤主题(topics)来分类别储存数据流(records).
每个记录(record)由⼀个键(key)，⼀个值(value)和⼀个时间戳(timestamp)组成
Kafka有4个核⼼APIs:
Producer API负责⽣产数据流，允许应⽤程序将记录流发布到⼀个或多个Kafka主题(topics).
Consumer API负责使⽤数据流，允许应⽤程序订阅⼀个或多个主题并处理为其⽣成的数据流.
Streams API负责处理或转化数据流，允许应⽤程序充当数据流处理器的⾓⾊, 处理来⾃⼀个或多个主题的输⼊数据流，并产⽣输出数据流到⼀个或多个输出主题，⼀次来有效地将输⼊流转换成输出流.
Connector API负责将数据流与其他应⽤或系统结合，允许搭建建和运⾏可重复使⽤的⽣产者或消费者，将Kafka数据主题与现有应⽤程序或数据系统相连接的。 例如，关系数据库的连接器可能会将表的每个更改的事件，都捕获为⼀个数据流.
Kafka的客户端和服务器之间的通信是⽤⼀种简单，⾼性能，语⾔独⽴的TCP协议实现的. 此协议是版本化的并保持与旧版本的向后兼容性. 我们为Kafka提供了⼀个Java客户端, 但也⽀持很多其他语⾔的客户端.
作为Kafka对数据提供的核⼼抽象，我们先来深度探究⼀下主题(topic)这个概念 主题是发布的数据流的类别或名称。主题在Kafka中，总是⽀持多订阅者的; 也就是说，主题可以有零个，⼀个或多个消费者订阅写到相应主题的数据. 对应每⼀个主题，Kafka集会维护像⼀个如下这样的分区的⽇志:
每个分区都是是⼀个有序的，不可变的，并且不断被附加的记录序列，—也就是⼀个结构化提交⽇志(commit log).为了保证唯⼀标性识分区中的每个数据记录，分区中的记录每个都会被分配⼀个⼀个叫做偏移(offset)顺序的ID号. 通过⼀个可配置的保留期，Kafka集会保留所有被发布的数据，不管它们是不是已经被消费者处理. 例如，如果保留期设置为两天，则在发布记录后的两天内，数据都可以被消费，之后它将被丢弃以释放空间。 卡夫卡的性能是不为因为数据量⼤⼩⽽受影响的，因此长时间存储数据并不成问题。
事实上，在每个消费者上保留的唯⼀元数据是消费者在⽇志中的偏移位置。这个偏移由消费者控制：通常消费者会在读取记录时线性地提⾼其偏移值(offset++)，但实际上，由于偏移位置由消费者控制，它可以以任何顺序来处理数据记录。 例如，消费者可以重置为较旧的偏移量以重新处理来⾃过去的数据，或者跳过之前的记录，并从“现在”开始消费。 这种特征的组合意味着卡夫卡消费者⾮常轻量级 — 随意的开启和关闭并不会对其他的消费者有⼤的影响。例如，您可以使⽤我们的命令⾏⼯具tail来查看任何主题的内容，⽽⽆需更改任何现有消费者所消耗的内容。 ⽇志中的分区有⼏个⽬的。 ⾸先，它保证⽇志的扩展性，主题的⼤⼩不受单个服务器⼤⼩的限制。每个单独的分区⼤⼩必须⼩于托管它的服
务器磁盘⼤⼩，但主题可能有很多分区，因此它可以处理任意数量的海量数据。第⼆，它可以作为并⾏处理的单位 —
这个我们等下再多谈.
在Kafka集中，不同分区⽇志的分布在相应的不同的服务器节点上，每个服务器节点处理⾃⼰分区对应的数据和请求。每个分区都会被复制备份到⼏个(可配置)服务器节点，以实现容错容灾。 分布在不同节点的同⼀个分区都会有⼀个服务器节点作为领导者(”leader”)和0个或者多个跟随者(”followers”). 分区的领导者会处理所有的读和写请求，⽽跟随者只会被动的复制领导者.如果leader挂了, ⼀个follower 会⾃动变成leader。每个服务器都会作为其⼀些分区的领导者，但同时也可能作为其他分分区的跟随者，Kafka以此来实现在集内的负载平衡。
⽣产者将数据发布到他们选择的主题。 ⽣产者负责选择要吧数据分配给主题中哪个分区。这可以通过循环⽅式(round-robin)简单地平衡负载，或者可以根据某些语义分区(例如基于数据中的某些关键字)来完成。我们等⼀下就来讨论分区的使⽤！
消费者们使⽤消费组名称来标注⾃⼰，⼏个消费者共享⼀个组名，每⼀个发布到主题的数据会被传递到每个消费者组中的⼀个消费者实例。 消费者实例可以在不同的进程中或不同的机器上。 如果所有的消费者实例具有相同的消费者组，则记录将在所有的消费者实例上有效地负载平衡，每个数据
只发到了⼀个消费者 如果所有的消费者实例都有不同的消费者体，那么每个记录将被⼴播给所有的消费者进程，每个数据都发到了所有的消费者。
如上图，⼀个两个服务器节点的Kafka集， 托管着4个分区(P0-P3)，分为两个消费者. 消费者A有2个消费者实例，消费者B有4个. 然⽽，更常见的是，我们发现主题具有少量的消费者，每个消费者代表⼀个“逻辑订户”。每个组由许多消费者实例组成，保证可扩展性和容错能⼒。这可以说是“发布-订阅”语义，但⽤户是⼀组消费者⽽不是单个进程。 在Kafka中实现消费的⽅式，是通过将⽇志中的分区均分到消费者实例上，以便每个实例在任何时间都是“相应⼤⼩的⼀块”分区的唯⼀消费者。维护消费者组成员资格的过程，由卡夫卡协议动态处理。 如果新的实例加⼊组，他们将从组中的其他成员接管⼀些分区; 如果⼀个实例消失，其分区将被分发到剩余的实例。Kafka仅提供单个分区内的记录的顺序，⽽不是主题中的不同分区之间的总顺序。 每个分区排序结合按键分区，⾜以满⾜⼤多数应⽤程序的需求。 但是，如果您需要使⽤总顺序，则可以通过仅具有⼀个分区的主题来实现，尽管这仅意味着每个消费者组只有⼀个消费者进程。
在⾼可⽤的Kafka集中，我们有如下的保证:
⽣产者发送到特定主题分区的消息将按照发送的顺序进⾏追加。 也就是说，如果记录M1由与记录M2相同的制造者发送，并且⾸先发送
M1，则M1将具有⽐M2更低的偏移并且在⽇志中较早出现。
消费者实例观察到数据的顺序，与它们存储在⽇志中的顺序⼀致。
对于具有复制因⼦N的主题，我们将容忍最多N-1个服务器故障，⽽不会丢失提交到⽇志的任何记录。
更多有关这些“保证”的细节会在有关设计的⽂档中。
Kafka的数据流概念与传统的企业消息系统相⽐如何？ 消息系统传统上有两种模式: 队列和发布-订阅. 在队列中，消费者池可以从服务器读取，每条记录都转到其中⼀个; 在发布订阅中，记录将⼴播给所有消费者。 这两个模型中的每⼀个都有优点和缺点。 排队的优点是它允许您在多个消费者实例上分配数据处理，从⽽可以扩展您的处理。 不幸的是，队列⽀持多⽤户，⼀旦⼀个进程读取数据就没有了。 发布订阅允许您将数据⼴播到多个进程，但⽆法缩放和扩容，因为每个消息都发送给每个订阅⽤户。 卡夫卡消费体概念概括了这两个概念。 与队列⼀样，消费者组允许您通过⼀系列进程(消费者组的成员)来划分处理。 与发布订阅⼀样，Kafka允许您将消息⼴播到多个消费者组。 Kafka 模型的优点是，每个主题都具有这两个属性，它可以进⾏缩放处理，也是多⽤户的，没有必要选择⼀个⽽放弃另⼀个。 卡夫卡也⽐传统的消息系统有更强⼤的消息次序保证。 传统队列在服务器上保存顺序的记录，如果多个消费者从队列中消费，则服务器按照存储顺序输出记录。 然⽽，虽然服务器按顺序输出记录，但是记录被异步传递给消费者，所以它们可能会在不同的消费者处按不确定的顺序到达。 这意味着在
并⾏消耗的情况下，记录的排序丢失。 消息传递系统通常通过使“唯⼀消费者”的概念只能让⼀个进程从队列中消费，但这当然意味着处理中没有并⾏性。 卡夫卡做得更好。通过分区，在⼀个主题之内的并⾏处理，Kafka能够在消费者流程池中，即提供排序保证，也负载平衡。这是通过将主题中的分区分配给消费者组中的消费者来实现的，以便每⼀个分区由组中的⼀个消费者使⽤。 通过这样做，我们确保消费者是该分区的唯⼀读者，并按顺序消耗数据。 由于有许多分区，这仍然平衡了许多消费者实例的负载。 但是请注意，消费者组中的消费者实例个数不能超过分区的个数。
Kafka作为存储系统
任何允许发布消息，解耦使⽤消息的消息队列，都在本质上充当传输中途消息的存储系统。 卡夫卡的不同之处在于它是⼀个很好的存储系统。 写⼊Kafka的数据写⼊磁盘并进⾏复制以进⾏容错。 Kafka允许⽣产者等待写⼊完成的确认，这样在数据完全复制之前，写⼊是未完成的，并且即使写⼊服务器失败，也保证持久写⼊。 Kafka的磁盘结构使⽤可以很好的扩容，⽆论您在服务器上是否有50KB或50TB的持久数据，Kafka都能保持稳定的性能。 由于对存储花费了很多精⼒，并允许客户端控制其读取位置，您可以将Kafka视为，专⽤于⾼性能，低延迟的⽇志存储复制和传播的专⽤分布式⽂件系统。
Kafka⽤于流数据处理
仅读取，写⼊和存储数据流是不够的，Kafka的⽬的是实现流的实时处理。 在Kafka中，流处理器的定
义是：任何从输⼊主题接收数据流，对此输⼊执⾏⼀些处理，并⽣成持续的数据流道输出主题的组件。 例如，零售应⽤程序可能会收到销售和出货的输⼊流，并输出根据该数据计算的重新排序和价格调整的输出流。 当然我们也可以直接⽤producer and consumer APIs在做简单的出列. 然⽽对于更复杂的转换，Kafka提供了⼀个完全集成的Streams API。这允许我们构建应⽤程序进⾏更复杂的运算，或者聚合，或将流连接在⼀起。 该设施有助于解决这种类型的应⽤程序⾯临的困难问题：处理⽆序数据，重新处理输⼊作为代码更改，执⾏有状态计算等。 Stream API基于Kafka提供的核⼼原语构建：它使⽤⽣产者和消费者API进⾏输⼊，使⽤Kafka进⾏有状态存储，并在流处理器实例之间使⽤相同的组机制来实现容错。
放在⼀起，综上所述
消息系统，数据存储和流处理的这种组合似乎是不寻常的，但是这些特性对于Kafka作为流媒体平台的⾓⾊⾄关重要。 像HDFS这样的分布式⽂件系统允许存储⽤于批处理的静态⽂件。 本质上，这样的系统允许存储和处理来⾃过去的历史数据。 传统的企业邮消息系统允许处理将在您订阅之后到达的未来消息。 以这种⽅式构建的应⽤程序在未来数据到达时即使处理。 Kafka结合了这两种功能，这种组合对于Kafka 作为流应⽤程序和流数据管道平台来说⾄关重要。 通过组合存储和低延迟订阅，流式应⽤程序可以以相同的⽅式处理过去和未来的数据。这是⼀个单⼀的应⽤程序可以处理历史记录数据，⽽不是在到达最后⼀个记录时结束，它可以随着将来的数据到达⽽继续处理。 这是⼀个⼴泛的流处理概
念，其中包含批处理以及消息驱动应⽤程序。 同样，对于流数据流⽔线，订阅到实时事件的组合使得可以使⽤Kafka进⾏⾮常低延迟的管道传输; 可靠地存储数据的能⼒使得可以将其⽤于必须保证数据传送的关键数据，或者与仅负载数据的离线系统集成，或者可能会长时间停机以进⾏维护。 流处理设备可以在数据到达时转换数据 有关Kafka提供的保证，apis和功能的更多信息，请参阅其余部分documentation.

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。