Kafka官网翻译中文版Word文件下载.docx

Kafka官网翻译中文版Word文件下载.docx

《Kafka官网翻译中文版Word文件下载.docx》由会员分享，可在线阅读，更多相关《Kafka官网翻译中文版Word文件下载.docx（9页珍藏版）》请在冰豆网上搜索。

高并发：

支持数千个客户端同时读写

1.3Kafka一些重要设计思想

下面介绍先大体介绍一下Kafka的主要设计思想，可以让相关人员在短时间内了解到kafka相关特性，如果想深入研究，后面会对其中每一个特性都做详细介绍。

Consumergroup：

各个consumer可以组成一个组，每个消息只能被组中的一个consumer消费，如果一个消息可以被多个consumer消费的话，那么这些consumer必须在不同的组。

消息状态：

在Kafka中，消息的状态被保存在consumer中，broker不会关心哪个消息被消费了被谁消费了，只记录一个offset值（指向partition中下一个要被消费的消息位置），这就意味着如果consumer处理不好的话，broker上的一个消息可能会被消费多次。

消息持久化：

Kafka中会把消息持久化到本地文件系统中，并且保持极高的效率。

消息有效期：

Kafka会长久保留其中的消息，以便consumer可以多次消费，当然其中很多细节是可配置的。

批量发送：

Kafka支持以消息集合为单位进行批量发送，以提高push效率。

push-and-pull 

:

Kafka中的Producer和consumer采用的是push-and-pull模式，即Producer只管向brokerpush消息，consumer只管从brokerpull消息，两者对消息的生产和消费是异步的。

Kafka集群中broker之间的关系：

不是主从关系，各个broker在集群中地位一样，我们可以随意的增加或删除任何一个broker节点。

负载均衡方面：

Kafka提供了一个metadataAPI来管理broker之间的负载（对Kafka0.8.x而言，对于0.7.x主要靠zookeeper来实现负载均衡）。

同步异步：

Producer采用异步push方式，极大提高Kafka系统的吞吐率（可以通过参数控制是采用同步还是异步方式）。

分区机制partition：

Kafka的broker端支持消息分区，Producer可以决定把消息发到哪个分区，在一个分区中消息的顺序就是Producer发送消息的顺序，一个主题中可以有多个分区，具体分区的数量是可配置的。

离线数据装载：

Kafka由于对可拓展的数据持久化的支持，它也非常适合向Hadoop或者数据仓库中进行数据装载。

插件支持：

现在不少活跃的社区已经开发出不少插件来拓展Kafka的功能，如用来配合Storm、Hadoop、flume相关的插件。

1.4TopicsandLogs

先来看一下Kafka提供的一个抽象概念：

topic。

一个topic是对一组消息的归纳。

对每个topic，Kafka对它的日志进行了分区，如下图所示：

每个分区都由一系列有序的、不可变的消息组成，这些消息被连续的追加到分区中。

分区中的每个消息都有一个连续的序列号叫做offset,用来在分区中唯一的标识这个消息。

在一个可配置的时间段内，Kafka集群保留所有发布的消息，不管这些消息有没有被消费。

比如，如果消息的保存策略被设置为2天，那么在一个消息被发布的两天时间内，它都是可以被消费的。

之后它将被丢弃以释放空间。

Kafka的性能是和数据量无关的常量级的，所以保留太多的数据并不是问题。

实际上每个consumer唯一需要维护的数据是消息在日志中的位置，也就是offset.这个offset有consumer来维护：

一般情况下随着consumer不断的读取消息，这offset的值不断增加，但其实consumer可以以任意的顺序读取消息，比如它可以将offset设置成为一个旧的值来重读之前的消息。

以上特点的结合，使Kafkaconsumers非常的轻量级：

它们可以在不对集群和其他consumer造成影响的情况下读取消息。

你可以使用命令行来"

tail"

消息而不会对其他正在消费消息的consumer造成影响。

将日志分区可以达到以下目的：

首先这使得每个日志的数量不会太大，可以在单个服务器器上保存。

另外每个分区可以单独发布和消费，为并发操作topic提供了一种可能。

1.5Distribution

每个分区在Kafka集群的若干服务器中都有副本，这样这些持有副本的服务器可以共同处理数据和请求，副本数量是可以配置的。

副本使Kafka具备了容错能力。

每个分区都由一个服务器作为“leader”，零或若干服务器作为“followers”,leader负责处理消息的读和写，followers则去复制leader.如果leaderdown了，followers中的一台则会自动成为leader。

集群中的每个服务器都会同时扮演两个角色：

作为它所持有的一部分分区的leader，同时作为其他分区的followers，这样集群就会具有较好的负载均衡。

1.6Producers

Producer将消息发布到它指定的topic中,并负责决定发布到哪个分区。

通常简单的由负载均衡机制随机选择分区，但也可以通过特定的分区函数选择分区。

使用的更多的是第二种。

1.7Consumers

发布消息通常有两个模型:

队列模式和发布-订阅模式。

在队列模式中,消费者从同一个服务器读取，每个消息被其中的一个消费者读到,

在发布-订阅模式中，消息被广播给所有的消费者。

Kafka提供了一个概念---消费者组,概括了以上两种模式。

每一个消费者都属于某一个消费者组,topic中的消息被发布到每个组中的某一个消费者。

消费者可以在不同的进程中，也可以在不同的机器上。

如果所有的消费者都在一个组中，这就成为了传统的队列模式，在各消费者中实现负载均衡。

如果所有的消费者都不在不同的组中，这就成为了发布-订阅模式，所有的消息都被分发到所有的消费者中。

AtwoserverKafkaclusterhostingfourpartitions（P0-P3）withtwoconsumergroups.ConsumergroupAhastwoconsumerinstancesandgroupBhasfour.

相比传统的消息系统，Kafka可以很好的保证有序性。

传统的队列在服务器上保存有序的消息，如果多个consumers同时从这个服务器消费消息，服务器就会以消息存储的顺序向consumer分发消息。

虽然服务器按顺序发布消息，但是消息是被异步的分发到各consumer上，所以当消息到达时可能已经失去了原来的顺序，这意味着并发消费将导致顺序错乱。

为了避免故障，这样的消息系统通常使用“专用consumer”的概念，其实就是只允许一个消费者消费消息，当然这就意味着失去了并发性。

在这方面Kafka做的更好，通过分区的概念，Kafka可以在多个consumer组并发的情况下提供较好的有序性和负载均衡。

将每个分区分只分发给一个consumer组，这样一个分区就只被这个组的一个consumer消费，就可以顺序的消费这个分区的消息。

因为有多个分区，依然可以在多个consumer组之间进行负载均衡。

注意consumer组的数量不能多于分区的数量，也就是有多少分区就允许多少并发消费。

Kafka只能保证一个分区之内消息的有序性，在不同的分区之间是不可以的，这已经可以满足大部分应用的需求。

如果需要topic中所有消息的有序性，那就只能让这个topic只有一个分区，当然也就只有一个consumer组消费它。

1.8Guarantees

Kafka做出下面的保证：

●消息按照发送的顺序被append到指定的topic的指定分区。

●消费者按消息的存储顺序被读取到。

●对于一个N副本的topic，能容忍N-1个服务器宕机，保证消息提交到log。

2使用场景

2.1消息系统

与其他传统的消息系统（ 

ActiveMQ 

、 

RabbitMQ等）相比，Kafka有高吞吐量，内置可分区，高容错，可重复的优势，这使其适用于消息产出量大的应用。

对于一些常规的消息系统,kafka是个不错的选择;

partitons/replication和容错,可以使kafka具有良好的扩展性和性能优势.不过到目前为止,我们应该很清楚认识到,kafka并没有提供JMS中的"

事务性"

"

消息传输担保（消息确认机制）"

消息分组"

等企业级特性;

kafka只能使用作为"

常规"

的消息系统,在一定程度上,尚未确保消息的发送与接收绝对可靠（比如,消息重发,消息发送丢失等）。

注：

红色内容摘自网络。

2.2WebsiteActivityTracking

TheoriginalusecaseforKafkawastobeabletorebuildauseractivitytrackingpipelineasasetofreal-timepublish-subscribefeeds.Thismeanssiteactivity（pageviews,searches,orotheractionsusersmaytake）ispublishedtocentraltopicswithonetopicperactivitytype.Thesefeedsareavailableforsubscriptionforarangeofusecasesincludingreal-timeprocessing,real-timemonitoring,andloadingintoHadooporofflinedatawarehousingsystemsforofflineprocessingandreporting.

Activitytrackingisoftenveryhighvolumeasmanyactivitymessagesaregeneratedforeachuserpageview.

2.3Metrics

Kafkaisoftenusedforoperationalmonitoringdata.Thisinvolvesaggregatingstatisticsfromdistributedapplicationstoproducecentralizedfeedsofoperationaldata.

2.4LogAggregation

ManypeopleuseKafkaasareplacementforalogaggregationsolution.Logaggregationtypicallycollectsphysicallogfilesoffserversandputstheminacentralplace（afileserverorHDFSperhaps）forprocessing.Kafkaabstractsawaythedetailsoffilesandgivesacleanerabstractionoflogoreventdataasastreamofmessages.Thisallowsforlower-latencyprocessingandeasiersupportformultipledatasourcesanddistributeddataconsumption.Incomparisontolog-centricsystemslikeScribeorFlume,Kafkaoffersequallygoodperformance,strongerdurabilityguaranteesduetoreplication,andmuchlowerend-to-endlatency.

2.5StreamProcessing

Manyusersendupdoingstage-wiseprocessingofdatawheredataisconsumedfromtopicsofrawdataandthenaggregated,enriched,orotherwisetransformedintonewKafkatopicsforfurtherconsumption.ForexampleaprocessingflowforarticlerecommendationmightcrawlarticlecontentfromRSSfeedsandpublishittoan"

articles"

topic;

furtherprocessingmighthelpnormalizeordeduplicatethiscontenttoatopicofcleanedarticlecontent;

afinalstagemightattempttomatchthiscontenttousers.Thiscreatesagraphofreal-timedataflowoutoftheindividualtopics. 

Storm 

and 

Samza 

arepopularframeworksforimplementingthesekindsoftransformations.

2.6EventSourcing

Eventsourcing 

isastyleofapplicationdesignwherestatechangesareloggedasatime-orderedsequenceofrecords.Kafka'

ssupportforverylargestoredlogdatamakesitanexcellentbackendforanapplicationbuiltinthisstyle.

2.7CommitLog

Kafkacanserveasakindofexternalcommit-logforadistributedsystem.Theloghelpsreplicatedatabetweennodesandactsasare-syncingmechanismforfailednodestorestoretheirdata.The 

logcompaction 

featureinKafkahelpssupportthisusage.InthisusageKafkaissimilarto 

ApacheBookKeeper 

project.

3集群搭建

3.1Step1:

Downloadthecode

Download 

the0.8.2.0releaseandun-tarit.

>

tar-xzfkafka_2.10-0.8.2.0.tgz

cdkafka_2.10-0.8.2.0

3.2Step2:

Starttheserver

KafkausesZooKeepersoyouneedtofirststartaZooKeeperserverifyoudon'

talreadyhaveone.Youcanusetheconveniencescriptpackagedwithkafkatogetaquick-and-dirtysingle-nodeZooKeeperinstance.

bin/zookeeper-server-start.shconfig/zookeeper.properties

[2013-04-2215:

01:

37,495]INFOReadingconfigurationfrom:

config/zookeeper.properties（org.apache.zookeeper.server.quorum.QuorumPeerConfig）

...

NowstarttheKafkaserver:

bin/kafka-server-start.shconfig/server.properties

47,028]INFOVerifyingproperties（kafka.utils.VerifiableProperties）

47,051]INFOPropertysocket.send.buffer.bytesisoverriddento1048576（kafka.utils.VerifiableProperties）

3.3Step3:

Createatopic

Let'

screateatopicnamed"

test"

withasinglepartitionandonlyonereplica:

bin/kafka-topics.sh--create--zookeeperlocalhost:

2181--replication-factor1--partitions1--topictest

Wecannowseethattopicifwerunthelisttopiccommand:

bin/kafka-topics.sh--list--zookeeperlocalhost:

2181

test

Alternatively,insteadofmanuallycreatingtopicsyoucanalsoconfigureyourbrokerstoauto-createtopicswhenanon-existenttopicispublishedto.

3.4Step4:

Sendsomemessages

Kafka使用一个简单的命令行producer，从文件中或者从标准输入中读取消息并发送到服务端。

默认的每行命令将发送一条消息。

运行producer并在控制台中输一些消息，这些消息将被发送到服务端：

bin/kafka-console-producer.sh--broker-listlocalhost:

9092--topictest

Thisisamessage

Thisisanothermessage

3.5Step5:

Startaconsumer

Kafka也有一个命令行consumer可以读取消息并输出到标准输出：

bin/kafka-console-consumer.sh--zookeeperlocalhost:

2181--topictest--from-beginning

你在一个终端中运行consumer命令行，另一个终端中运行producer命令行，就可以在一个终端输入消息，另一个终端读取消息。

这两个命令都有自己的可选参数，可以在运行的时候不加任何参数可以看到帮助信息。

3.6Step6:

搭建一个多个broker的集群

刚才只是启动了单个broker，现在启动有3个broker组成的集群，这些broker节点也都是在本机上的：

首先为每个节点编写配置文件：

cpconfig/server.propertiesconfig/server-1.properties

cpconfig/server.propertiesconfig/server-2.properties

在拷贝出的新文件中添加以下参数：

config/server-1.properties:

broker.id=1

port=9093

log.dir=/tmp/kafka-logs-1

config/server-2.properties:

broker.id=2

port=9094

log.dir=/tmp/kafka-logs-2

broker.id在集群中唯一的标注一个节点，因为在同一个机器上，所以必须制定不同的端口和日志文件，避免数据被覆盖。

刚才已经启动了Zookeeper和一个节点，现在启动另外两个节点：

bin/kafka-server-start.shconfig/server-1.properties&

bin/kafka-server-start.shconfig/server-2.properties&

创建一个拥有3个副本的topic:

2181--replication-factor3--partitions1--topicmy-replicated-topic

现在我们搭建了一个集群，怎么知道每个节点的信息呢？

运行“"

describetopics”命令就可以了：

下面解释一下这些输出。

第一行是对所有分区的一个描述，然后每个分区都会对应一行，因为我们只有一个分区所以下面就只加了一行。

∙leader：

负责处理消息的读和写，leader是从所有节点中随机选择的.

∙replicas：

列出了所有的副本节点，不管节点是否在服务中.

∙isr：

是正在服务中的节点.

在我们的例子中，节点1是作为leader运行。

向topic发送消息：

4配置

4.1生产者配置

必要配置:

1.metadata.broker.list

2.request.required.acks

3.producer.type

4.serializer.class

5其他参考资料