1.入门指南
1.1简介
Apache的Kafka?是一个分布式流平台(adistributedstreamingplatform)。这到底意味着什么？我们认为，一个流处理平台应该具有三个关键能力：
它可以让你发布和订阅记录流。在这方面，它类似于一个消息队列或企业消息系统。
它可以让你持久化收到的记录流，从而具有容错能力。
它可以让你处理收到的记录流。
Kafka擅长哪些方面？
它被用于两大类应用：
建立实时流数据管道从而能够可靠地在系统或应用程序之间的共享数据
构建实时流应用程序，能够变换或者对数据
进行相应的处理。
想要了解Kafka如何具有这些能力，让我们从下往上深入探索Kafka的能力。
首先，明确几个概念：
Kafka是运行在一个或多个服务器的集群(Cluster)上的。
Kafka集群分类存储的记录流被称为主题(Topics)。
每个消息记录包含一个键，一个值和时间戳。
Kafka有四个核心API：
生产者API允许应用程序发布记录流至一个或多个Kafka的话题(Topics)。
消费者API允许应用程序订阅一个或多个主题，并处理这些主题接收到的记录流。
StreamsAPI允许应用程序充当流处理器（streamprocessor），从一个或多个主题获取输入流，并生产一个输出流至一个或多个的主题，能够有效地变换输入流为输出流。
ConnectorAPI允许构建和运行可重用的生产者或消费者，能够把Kafka主题连接到现有的应用程序或数据系统。例如，一个连接到关系数据库的连接器(connector)可能会获取每个表的变化。
Kafka的客户端和服务器之间的通信是靠一个简单的，高性能的，与语言无关的TCP协议完成的。这个协议有不同的版本，并保持向后兼容旧版本（向前兼容旧版本？）。Kafka不光提供了一个Java客户端，还有许多语言版本的客户端。
主题和日志
让我们先来了解Kafka的核心抽象概念记录流–主题。
主题是一种分类或发布的一系列记录的名义上的名字。Kafka的主题始终是支持多用户订阅的;也就是说，一个主题可以有零个，一个或多个消费者订阅写入的数据。
对于每一个主题，Kafka集群保持一个分区日志文件，看下图：
每个分区是一个有序的，不可变的消息序列，新的消息不断追加到这个有组织的有保证的日志上。分区会给每个消息记录分配一个顺序ID号–偏移量，能够唯一地标识该分区中的每个记录。
Kafka集群保留所有发布的记录，不管这个记录有没有被消费过，Kafka提供可配置的保留策略去删除旧数据(还有一种策略根据分区大小删除数据)。例如，如果将保留策略设置为两天，在记录公布后两天，它可用于消费，之后它将被丢弃以腾出空间。Kafka的性能跟存储的数据量的大小无关，所以将数据存储很长一段时间是没有问题的。
事实上，保留在每个消费者元数据中的最基础的数据就是消费者正在处理的当前记录的偏移量(offset)或位置(position)。这种偏移是由消费者控制：通常偏移会随着消费者读取记录线性前进，但事实上，因为其位置是由消费者进行控制，消费者可以在任何它喜欢的位置读取记录。例如，消费者可以恢复到旧的偏移量对过去的数据再加工或者直接跳到最新的记录，并消费从“现在”开始的新的记录。
这些功能的结合意味着，实现Kafka的消费者的代价都是很小的，他们可以增加或者减少而不会对集群或其他消费者有太大影响。例如，你可以使用我们的命令行工具去追随任何主题，而且不会改变任何现有的消费者消费的记录。
数据日志的分区，一举数得。首先，它们允许数据能够扩展到更多的服务器上去。每个单独的分区的大小受到承载它的服务器的限制，但一个话题可能有很多分区，以便它能够支持海量的的数据。其次，更重要的意义是分区是进行并行处理的基础单元。
分布式
日志的分区会跨服务器的分布在Kafka集群中，每个服务器会共享分区进行数据请求的处理。每个分区可以配置一定数量的副本分区提供容错能力。
每个分区都有一个服务器充当“leader”和零个或多个服务器充当“followers”。leader处理所有的读取和写入分区的请求，而followers被动的从领导者拷贝数据。如果leader失败了，followers之一将自动成为新的领导者。每个服务器可能充当一些分区的leader和其他分区的follower，这样的负载就会在集群内很好的均衡分配。
生产者
生产者发布数据到他们所选择的主题。生产者负责选择把记录分配到主题中的哪个分区。这可以使用轮询算法(round-robin)进行简单地平衡负载，也可以根据一些更复杂的语义分区算法（比如基于记录一些键值）来完成。
消费者
消费者以消费群（consumergroup）的名称来标识自己，每个发布到主题的消息都会发送给订阅了这个主题的消费群里面的一个消费者的一个实例。消费者的实例可以在单独的进程或单独的机器上。
如果所有的消费者实例都属于相同的消费群，那么记录将有效地被均衡到每个消费者实例。
如果所有的消费者实例有不同的消费群，那么每个消息将被广播到所有的消费者进程。
两个服务器的Kafka集群具有四个分区（P0-P3）和两个消费群。A消费群有两个消费者，B群有四个。
更常见的是，我们会发现主题有少量的消费群，每一个都是“逻辑上的订阅者”。每组都是由很多消费者实例组成，从而实现可扩展性和容错性。这只不过是发布–订阅模式的再现，区别是这里的订阅者是一组消费者而不是一个单一的进程的消费者。
Kafka消费群的实现方式是通过分割日志的分区，分给每个Consumer实例，使每个实例在任何时间点的都可以“公平分享”独占的分区。维持消费群中的成员关系的这个过程是通过Kafka动态协议处理。如果新的实例加入该组，他将接管该组的其他成员的一些分区;如果一个实例死亡，其分区将被分配到剩余的实例。
Kafka只保证一个分区内的消息有序，不能保证一个主题的不同分区之间的消息有序。分区的消息有序与依靠主键进行数据分区的能力相结合足以满足大多数应用的要求。但是，如果你想要保证所有的消息都绝对有序可以只为一个主题分配一个分区，虽然这将意味着每个消费群同时只能有一个消费进程在消费。
保证
Kafka提供了以下一些高级别的保证：
由生产者发送到一个特定的主题分区的消息将被以他们被发送的顺序来追加。也就是说，如果一个消息M1和消息M2都来自同一个生产者，M1先发，那么M1将有一个低于M2的偏移，会更早在日志中出现。
消费者看到的记录排序就是记录被存储在日志中的顺序。
对于副本因子N的主题，我们将承受最多N-1次服务器故障切换而不会损失任何的已经保存的记录。
对这些保证的更多细节可以参考文档的设计部分。
Kafka作为消息系统
如何将Kafka的流的概念和传统的企业信息系统作比较？
消息处理模型历来有两种：队列和发布-订阅。在队列模型中，一组消费者可以从服务器读取记录，每个记录都会被其中一个消费者处理;在发布-订阅模式里，记录被广播到所有的消费者。这两种模式都具有一定的优点和弱点。队列的优点是它可以让你把数据分配到多个消费者去处理，它可以让您扩展你的处理能力。不幸的是，队列不支持多个订阅者，一旦一个进程读取了数据，这个数据就会消失。发布-订阅模式可以让你广播数据到多个进程，但是因为每一个消息发送到每个订阅者，没办法对订阅者处理能力进行扩展。
Kafka的消费群的推广了这两个概念。消费群可以像队列一样让消息被一组进程处理（消费群的成员），与发布–订阅模式一样，Kafka可以让你发送广播消息到多个消费群。
Kafka的模型的优点是，每个主题都具有这两个属性，它可以扩展处理能力，也可以实现多个订阅者，没有必要二选一。
Kafka比传统的消息系统具有更强的消息顺序保证的能力。
传统的消息队列的消息在队列中是有序的，多个消费者从队列中消费消息，服务器按照存储的顺序派发消息。然而，尽管服务器是按照顺序派发消息，但是这些消息记录被异步传递给消费者，消费者接收到的消息也许已经是乱序的了。这实际上意味着消息的排序在并行消费中都将丢失。消息系统通常靠“排他性消费”(exclusiveconsumer)来解决这个问题，只允许一个进程从队列中消费，当然，这意味着没有并行处理的能力。
Kafka做的更好。通过一个概念：并行性-分区-主题实现主题内的并行处理，Kafka是能够通过一组消费者的进程同时提供排序保证和负载均衡。每个主题的分区指定给每个消费群中的一个消费者，使每个分区只由该组中的一个消费者所消费。通过这样做，我们确保消费者是一个分区唯一的读者，从而顺序的消费数据。因为有许多的分区，所以负载还能够均衡的分配到很多的消费者实例上去。但是请注意，一个消费群的消费者实例不能比分区数量多。
Kafka作为存储系统
任何消息队列都能够解耦消息的生产和消费，还能够有效地存储正在传送的消息。Kafka与众不同的是，它是一个非常好的存储系统。
Kafka把消息数据写到磁盘和备份分区。Kafka允许生产者等待返回确认，直到副本复制和持久化全部完成才认为成功，否则则认为写入服务器失败。
Kafka使用的磁盘结构很好扩展，Kafka将执行相同的策略不管你是有50KB或50TB的持久化数据。
由于存储的重要性，并允许客户控制自己的读取位置，你可以把Kafka认为是一种特殊用途的分布式文件系统，致力于高性能，低延迟的有保障的日志存储，能够备份和自我复制。
Kafka流处理
只是读，写，以及储存数据流是不够的，目的是能够实时处理数据流。
在Kafka中，流处理器是从输入的主题连续的获取数据流，然后对输入进行一系列的处理，并生产连续的数据流到输出主题。
例如，零售应用程序可能需要输入销售和出货量，根据输入数据计算出重新订购的数量和调整后的价格，然后输出到主题。
这些简单处理可以直接使用生产者和消费者的API做到。然而，对于更复杂的转换Kafka提供了一个完全集成的流API。这允许应用程序把一些重要的计算过程从流中剥离或者加入流一起。
这种设施可帮助解决这类应用面临的难题：处理杂乱的数据，改变代码去重新处理输入，执行有状态的计算等
流API建立在Kafka提供的核心基础单元之上：它使用生产者和消费者的API进行输入输出，使用Kafka存储有状态的数据，并使用群组机制在一组流处理实例中实现容错。
把功能组合起来
消息的传输，存储和流处理的组合看似不寻常却是Kafka作为流处理平台的关键。
像HDFS分布式文件系统，允许存储静态文件进行批量处理。像这样的系统允许存储和处理过去的历史数据。
传统的企业消息系统允许处理您订阅后才抵达的消息。这样的系统只能处理将来到达的数据。
Kafka结合了这些功能，这种结合对Kafka作为流应用平台以及数据流处理的管道至关重要。
通过整合存储和低延迟订阅，流处理应用可以把过去和未来的数据用相同的方式处理。这样一个单独的应用程序，不但可以处理历史的，保存的数据，当它到达最后一条记录不会停止，继续等待处理未来到达的数据。这是泛化了的的流处理的概念，包括了批处理应用以及消息驱动的应用。
同样，流数据处理的管道结合实时事件的订阅使人们能够用Kafka实现低延迟的管道;可靠的存储数据的能力使人们有可能使用它传输一些重要的必须保证可达的数据。可以与一个定期加载数据的线下系统集成，或者与一个因为维护长时间下线的系统集成。流处理的组件能够保证转换（处理）到达的数据。
有关Kafka提供的保证，API和功能的更多信息，看其余文件。
1.2使用案例
下面描述了一些使用ApacheKafka?的流行用例。更多的关于这些领域实践的概述，参考这个博客。
消息
Kafka能够很好的替代传统的消息中间件。消息中间件由于各种原因被使用（解耦数据的生产和消费，缓冲未处理的消息等）。相较于大多数消息处理系统，Kafka有更好的吞吐量，内置分区，副本复制和容错性，使其成为大规模消息处理应用的理想解决方案。
根据我们的经验消息的使用通常具有相对低的吞吐量，但可能需要端到端的低延迟，以及高可靠性的保证，这种低延迟和可靠性的保证恰恰是Kafka能够提供的。
在这一领域Kafka是能够和传统的消息系统相媲美的，例如ActiveMQ或RabbitMQ。
网站活动跟踪
最初的用例是用Kafka重建一个用户活动跟踪管道使之作为一组实时发布–订阅的数据源。这意味着网站活动（网页浏览，搜索，或其他可能的操作）被当作一组中心主题发布，每种活动被当作一个主题。这些数据源（feeds）可被一系列的应用订阅，包括实时处理，实时监测，加载到Hadoop系统或离线数据仓库系统进行离线处理和报告。
活动追踪通常会产生巨大的数据量，因为每个用户页面的浏览都会产生很多的活动消息。
测量
Kafka通常用于监测数据的处理。这涉及从分布式应用程序聚集统计数据，生产出集中的运行数据源feeds（以便订阅）。
日志聚合
许多人用Kafka作为日志聚合解决方案的替代品。日志聚合通常从服务器收集物理日志文件，并把它们放在一个集中的地方（文件服务器或HDFS）进行处理。Kafka抽象了文件的详细信息，把日志或事件数据的简洁抽象作为消息流传输。这为低时延的处理提供支持，而且更容易支持多个数据源和分布式的数据消费。相比集中式的日志处理系统，ScribeorFlume，Kafka提供同样良好的性能，而且因为副本备份提供了更强的可靠性保证和更低的端到端延迟。
流处理
Kafka的流数据管道在处理数据的时候包含多个阶段，其中原始输入数据从Kafka主题被消费然后汇总，加工，或转化成新主题用于进一步的消费或后续处理。例如，用于推荐新闻文章的数据流处理管道可能从RSS源抓取文章内容，并将其发布到“文章”主题;进一步的处理可能是标准化或删除重复数据，然后发布处理过的文章内容到一个新的话题;最后的处理阶段可能会尝试推荐这个内容给用户。这样的数据流处理管道基于各个主题创建了实时数据数据流程图。从版本0.10.0.0开始，ApacheKafka加入了轻量级的但功能强大的流处理库KafkaStreams，KafkaStreams支持如上所述的数据处理。除了KafkaStreams，可以选择的开源流处理工具包括ApacheStormandApacheSamza.
EventSourcingEventsourcing是一种应用程序设计风格，是按照时间顺序记录的状态变化的序列。Kafka的非常强大的存储日志数据的能力使它成为构建这种应用程序的极好的后端选择。
CommitLogKafka可以为分布式系统提供一种外部提交日志(中科白癜风微信账号中科白癜风医院爱心捐助
转载请注明：http://www.chongqinghg.com/fygfz/2327.html
