培训课程Kafka

《培训课程Kafka》由会员分享，可在线阅读，更多相关《培训课程Kafka（62页珍藏版）》请在装配图网上搜索。

1、 课程安排课程安排Kafka是什么kafka体系结构kafka设计理念简介*kafka通信协议kafka的伪分布安装、集群安装*kafka的shell操作、java操作*kafka设计理念*kafka producer和consumer开发*Kafka产生背景产生背景 Kafka 是分布式发布-订阅消息系统。它最初由 LinkedIn 公司开发，使用 Scala语言编写,之后成为 Apache 项目的一部分。Kafka 是一个分布式的，可划分的，多订阅者,冗余备份的持久性的日志服务。它主要用于处理活跃的流式数据。在大数据系统中，常常会碰到一个问题，整个大数据是由各个子系统组成，数据需要在各个子

2、系统中高性能，低延迟的不停流转。传统的企业消息系统并 不是非常适合大规模的数据处理。为了已在同时搞定在线应用（消息）和离线应用（数据文件，日志）Kafka 就出现了。Kafka 可以起到两个作用：降低系统组网复杂度降低编程复杂度，各个子系统不在是相互协商接口，各个子系统类似插口插在插座上，Kafka 承担高速数据总线的作用。kafka系列文章索引:http:/ 每秒可以生产约 25 万消息（50 MB），每秒处理 55 万消息（110 MB）。2.可进行持久化操作。将消息持久化到磁盘，因此可用于批量消费，例如 ETL，以及实时应用程序。通过将数据持久化到硬盘以及 replication 防止数

3、据丢失。3.分布式系统，易于向外扩展。所有的 producer、broker 和 consumer 都会有多个，均为分布式的。无需停机即可扩展机器。4.消息被处理的状态是在 consumer 端维护，而不是由 server 端维护。当失败时能自动平衡。5.支持 online 和 offline 的场景。Kafka的简介的简介设计关注重点：为生产者和消费者提供一个通用的API消息的持久化高吞吐量，可以满足百万级别消息处理对分布式和高扩展性的支持kafka最基本的架构是生产者发布一个消息到Kafka的一个主题（topic），这个主题即是由扮演KafkaServer角色的broker提供，消费者订阅

4、这个主题，然后从中获取消息.Kafka是如何解决查找效率的的问题呢？Kafka的两大法宝的两大法宝数据文件的分段：Kafka解决查询效率的手段之一是将数据文件分段；为数据文件建索引：索引优化：索引优化：稀疏存储，每隔一定字节的数据建立一条索引。为了进一步提高查找的效率，为了进一步提高查找的效率，Kafka为每个分段后的数据文件建立了为每个分段后的数据文件建立了索引文件，文件名与数据文件的名字是一样的，只是文件扩展名索引文件，文件名与数据文件的名字是一样的，只是文件扩展名为为.index。索引文件中包含若干个索引条目，每个条目表示数据文件中一条Message的索引。索引包含两个部分（均为4个字节

5、的数字），分别为相对offset和position。消息队列分类消息队列分类点对点点对点:消息生产者生产消息发送到queue中，然后消息消费者从queue中取出并且消费消息。注意：消息被消费以后，queue中不再有存储，所以消息消费者不可能消费到已经被消费的消息。Queue支持存在多个消费者，但是对一个消息而言，只会有一个消费者可以消费。发布发布/订阅订阅:消息生产者（发布）将消息发布到topic中，同时有多个消息消费者（订阅）消费该消息。和点对点方式不同，发布到topic的消息会被所有订阅者消费。消息队列消息队列MQ对比对比RabbitMQ：支持的协议多，非常重量级消息队列，对路由(Rout

6、ing)，负载均衡(Load balance)或者数据持久化都有很好的支持。ZeroMQ：号称最快的消息队列系统，尤其针对大吞吐量的需求场景，擅长的高级/复杂的队列，但是技术也复杂，并且只提供非持久性的队列。ActiveMQ：Apache下的一个子项，类似ZeroMQ，能够以代理人和点对点的技术实现队列。Redis：是一个key-Value的NOSql数据库，但也支持MQ功能，数据量较小，性能优于RabbitMQ，数据超过10K就慢的无法忍受Kafka部署架构部署架构Kafka集群架构集群架构Kafka的基本概念的基本概念 Topic：特指 Kafka 处理的消息源（feeds of mess

7、ages）的不同分类。Partition：Topic 物理上的分组，一个 topic 可以分为多个 partition，每个 partition 是一个有序的队列。partition 中的每条消息都会被分配一个有序的 id（offset）。Message：消息，是通信的基本单位，每个 producer 可以向一个 topic（主题）发布一些消息。Producers：消息和数据生产者，向 Kafka 的一个 topic 发布消息的过程叫做 producers。Consumers：消息和数据消费者，订阅 topics 并处理其发布的消息的过程叫做 consumers。Broker：缓存代理，Kaf

8、ka 集群中的一台或多台服务器统称为 broker。Kafka的的ProducersProducer将消息发布到指定的Topic中,同时Producer也能决定将此消息归属于哪个partition;比如基于round-robin方式或者通过其他的一些算法等.消息和数据生产者，向 Kafka 的一个 topic 发布消息的过程叫做 producers。异步发送批量发送可以很有效的提高发送效率。Kafka producer的异步发送模式允许进行批量发送，先将消息缓存在内存中，然后一次请求批量发送出去。Kafka的的BrokerBroker：缓存代理，Kafka 集群中的一台或多台服务器统称为 br

9、oker。为了减少磁盘写入的次数,broker会将消息暂时buffer起来,当消息的个数(或尺寸)达到一定阀值时,再flush到磁盘,这样减少了磁盘IO调用的次数。Kafka的的broker无状态机制无状态机制1.Broker没有副本机制，一旦broker宕机，该broker的消息将都不可用。2.Broker不保存订阅者的状态，由订阅者自己保存。3.无状态导致消息的删除成为难题（可能删除的消息正在被订阅），kafka采用基于时间的SLA(服务水平保证)，消息保存一定时间（通常为7天）后会被删除。4.消息订阅者可以rewind back到任意位置重新进行消费，当订阅者故障时，可以选择最小的off

10、set(id)进行重新读取消费消息。Kafka的的Consumers消息和数据消费者，订阅 topics 并处理其发布的消息的过程叫做 consumers。本质上kafka只支持Topic.每个consumer属于一个consumer group;反过来说,每个group中可以有多个consumer.发送到Topic的消息,只会被订阅此Topic的每个group中的一个consumer消费.在 kafka中,我们 可以认为一个group是一个订阅者,一个Topic中的每个partions,只会被一个订阅者中的一个consumer消费,不过一个 consumer可以消费多个partitions中

11、的消息.kafka只能保证一个partition中的消息被某个consumer消费时,消息是顺 序的.事实上,从Topic角度来说,消息仍不是有序的.注：kafka的设计原理决定,对于一个topic,同一个group中不能有多于partitions个数的consumer同时消费,否则将意味着某些consumer将无法得到消息.一个一个partition中的消息只会被中的消息只会被group中的一个中的一个consumer消费消费;每个group中consumer消息消费互相独立;Kafka的的Consumer group1.允许consumer group（包含多个consumer，如一个集群

12、同时消费）对一个topic进行消费，不同的consumer group之间独立订阅。2.为了对减小一个consumer group中不同consumer之间的分布式协调开销，指定partition为最小的并行消费单位，即一个group内的consumer只能消费不同的partition。Kafka的的Topics/Log一个Topic可以认为是一类消息，每个topic将被分成多partition(区),每个partition在存储层面是append log文件。任何发布到此partition的消息都会被直接追加到log文件的尾部，每条消息在文件中的位置称为offset（偏移量）,partiti

13、on是以文件的形式存储在文件系统中。Logs文件根据broker中的配置要求,保留一定时间后删除来释放磁盘空间。Partition：Topic 物理上的分组，一个 topic 可以分为多个 partition，每个 partition 是一个有序的队列。partition 中的每条消息都会被分配一个有序的 id（offset）。Kafka的的partitions 设计目的：设计目的：kafka基于文件存储.通过分区,可以将日志内容分散到多个server上,来避免文件尺寸达到单机磁盘的上限,每个partiton都会被当前server(kafka实例)保存;可以将一个topic切分多任意多个par

14、titions,来消息保存/消费的效率.越多的partitions意味着可以容纳更多的consumer,有效提升并发消费的能力.Kafka的的MessageMessage消息：是通信的基本单位，每个 producer 可以向一个 topic（主题）发布一些消息。Kafka中的Message是以topic为基本单位组织的，不同的topic之间是相互独立的。每个topic又可以分成几个不同的partition(每个topic有几个partition是在创建topic时指定的)，每个partition存储一部分Message。partition中的每条Message包含了以下三个属性：offset对

15、应类型：longMessageSize对应类型：int32data是message的具体内容Kafka的的MessageKafka的的offset每条消息在文件中的位置称为offset（偏移量）。offset 为一个long型数字，它是唯一标记一条消息。它唯一的标记一条消息。kafka并没有提供其他额外的索引机制来存储offset，因为在kafka中几 乎不允许对消息进行“随机读写”。Partition中的每条Message由offset来表示它在这个partition中的偏移量，这个offset不是该Message在partition数据文件中的实际存储位置，而是逻辑上一个值，它唯一确定了p

16、artition中的一条Message。因此，可以认为offset是partition中Message的id。Kafka的的 offset怎样记录每个consumer处理的信息的状态？在Kafka中仅保存了每个consumer已经处理数据的offset。这样有两个好处：1）保 存的数据量少 2）当consumer出错时，重新启动consumer处理数据时，只需从最近的offset开始处理数据即可。Kafka的消息处理机制的消息处理机制 1.发送到partitions中的消息将会按照它接收的顺序追加到日志中 2.对于消费者而言,它们消费消息的顺序和日志中消息顺序一致.3.如果Topic的repl

17、ication factor为N,那么允许N-1个kafka实例失效.Kafka的消息处理机制的消息处理机制4.kafka对消息的重复、丢失、错误以及顺序型没有严格的要求。5.kafka提供at-least-once delivery,即当consumer宕机后，有些消息可能会被重复delivery。6.因每个partition只会被consumergroup内的一个consumer消费，故kafka保证每个partition内的消息会被顺序的订阅。7.Kafka为每条消息为每条消息计算CRC校验，用于错误检测，crc校验不通过的消息会直接被丢弃掉。ack校验，当消费者消费成功，返回ack信息

18、！数据传输的事务定义数据传输的事务定义at most once:最多一次,这个和JMS中非持久化消息类似.发送一次,无论成败,将不会重发.at least once:消息至少发送一次,如果消息未能接受成功,可能会重发,直到接收成功.exactly once:消息只会发送一次.at most once:消费者fetch消息,然后保存offset,然后处理消息;当client保存offset之后,但是在消息处理过程中出现了异常,导致部分消息未能继续处理.那么此后未处理的消息将不能被fetch到,这就是at most once.at least once:消费者fetch消息,然后处理消息,然后保存

19、offset.如果消息处理成功之后,但是在保存offset阶段zookeeper异常导致保存操作未能执行成功,这就导致接下来再次fetch时可能获得上次已经处理过的消息,这就是at least once，原因offset没有及时的提交给zookeeper，zookeeper恢复正常还是之前offset状态.exactly once:kafka中并没有严格的去实现(基于2阶段提交,事务),我们认为这种策略在kafka中是没有必要的.注：通常情况下at-least-once是我们首选.(相比at most once而言,重复接收数据总比丢失数据要好).Kafka的储存策略的储存策略1.kafka以

20、topic来进行消息管理，每个topic包含多个part（ition），每个part对应一个逻辑log，有多个segment组成。2.每个segment中存储多条消息（见下图），消息id由其逻辑位置决定，即从消息id可直接定位到消息的存储位置，避免id到位置的额外映射。3.broker 收到发布消息往对应 partition 的最后一个 segment 上添加该消息，Kafka的储存策略的储存策略4.每个part在内存中对应一个index，记录每个segment中的第一条消息偏移。5.发布者发到某个topic的 消息会被均匀的分布到多个part上（随机或根据用户指定的回调函数进行分布），bro

21、ker收到发布消息往对应part的最后一个segment上添加 该消息，当某个segment上的消息条数达到配置值或消息发布时间超过阈值时，segment上的消息会被flush到磁盘，只有flush到磁盘上的 消息订阅者才能订阅到，segment达到一定的大小后将不会再往该segment写数据，broker会创建新的segment。Kafka的数据传输的数据传输1.发布者每次可发布多条消息（将消息加到一个消息集合中发布），sub每次迭代一条消息。2.不创建单独的cache，使用系统的page cache。发布者顺序发布，订阅者通常比发布者滞后一点点，直接使用linux的page cache效果

22、也比较后，同时减少了cache管理及垃圾收集的开销。3.使用sendfile优化网络传输，减少一次内存拷贝。Kafka的消息发送的流程的消息发送的流程由于 kafka broker 会持久化数据，broker 没有内存压力，因此，consumer 非常适合采取 pull 的方式消费数据Producer 向Kafka（push）推数据consumer 从kafka 拉（pull）数据。kafka的消息发送的流程的消息发送的流程消息处理的优势：消息处理的优势：1.简化 kafka 设计2.consumer 根据消费能力自主控制消息拉取速度3.consumer 根据自身情况自主选择消费模式，例如批量

23、，重复消费，从尾端开始消费等4.kafka 集群接收到 Producer 发过来的消息后，将其持久化到硬盘，并保留消息指定时长（可配置），而不关注消息是否被消费。Kafka设计原理实现设计原理实现1.直接使用 linux 文件系统的 cache，来高效缓存数据。2.显式分布式，即所有的 producer、broker 和 consumer 都会有多个，均为分布式的。Producer 和 broker 之间没有负载均衡机制。broker 和 consumer 之间利用 zookeeper 进行负载均衡。所有 broker 和 consumer 都会在 zookeeper 中进行注册，且 zook

24、eeper 会保存他们的一些元数据信息。如果某个 broker 和 consumer 发生了变化，所有其他的 broker 和 consumer 都会得到通知。Kafka设计原理实现设计原理实现1.kafka 以 topic 来进行消息管理，发布者发到某个 topic 的消息会被均匀的分布到多个 partition上2.每个 topic 包含多个 partition，每个 part 对应一个逻辑 log，有多个 segment 组成。3.每个 segment 中存储多条消息，消息 id 由其逻辑位置决定，即从消息 id 可直接定位到消息的存储位置，避免 id 到位置的额外映射。4.每个 par

25、t 在内存中对应一个 index，记录每个 segment 中的第一条消息偏移。5.当某个 segment 上的消息条数达到配置值或消息发布时间超过阈值时，segment 上的消息会被 flush 到磁盘，只有 flush 到磁盘上的消息订阅者才能订阅到，segment 达到一定的大小后将不会再往该 segment 写数据，broker 会创建新的 segment。Kafka的通讯协议的通讯协议Kafka的Producer、Broker和Consumer之间采用的是一套自行设计基于TCP层的协议，根据业务需求定制，而非实现一套类似Protocol Buffer的通用协议。基本数据类型：基本数据

26、类型：定长数据类型：定长数据类型：int8,int16,int32和int64，对应到Java中就是byte,short,int和long。变长数据类型：变长数据类型：bytes和string。变长的数据类型由两部分组成，分别是一个有符号整数N(表示内容的长度)和N个字节的内容。其中，N为-1表示内容为null。bytes的长度由int32表示，string的长度由int16表示。数组：数组：数组由两部分组成，分别是一个由int32类型的数字表示的数组长度N和N个元素。Kafka的通讯协议的通讯协议Kafka通讯的基本单位是Request/Response基本结构：RequestOrRespo

27、nse=MessageSize(RequestMessage|ResponseMessage)通讯过程：通讯过程：客户端打开与服务器端的Socket往Socket写入一个int32的数字(数字表示这次发送的Request有多少字节)服务器端先读出一个int32的整数从而获取这次Request的大小然后读取对应字节数的数据从而得到Request的具体内容服务器端处理了请求后，也用同样的方式来发送响应。名称名称类型类型描述描述MessageSizeint32表示RequestMessage或者ResponseMessage的长度RequestMessageResponseMessage表示Requ

28、est或者Response的内容Kafka的通讯协议的通讯协议RequestMessage结构:RequestMessage=ApiKey ApiVersion CorrelationId ClientId Request名称名称类型类型描述描述ApiKeyint16表示这次请求的API编号ApiVersionint16表示请求的API的版本，有了版本后就可以做到后向兼容CorrelationIdint32由客户端指定的一个数字唯一标示这次请求的id，服务器端在处理完请求后也会把同样的CorrelationId写到Response中，这样客户端就能把某个请求和响应对应起来了。ClientIds

29、tring客户端指定的用来描述客户端的字符串，会被用来记录日志和监控，它唯一标示一个客户端。Request-Request的具体内容。Kafka的通讯协议的通讯协议ResponseMessage结构:ResponseMessage=CorrelationId ResponseKafka采用是经典的Reactor(同步IO)模式，也就是1个Acceptor响应客户端的连接请求，N个Processor来读取数据，这种模式可以构建出高 性能的服务器。名称名称类型类型描述描述CorrelationIdint32对应Request的CorrelationId。Response-对应Request的Res

30、ponse，不同的Request的Response的字段是不一样的。Kafka的通讯协议的通讯协议Message:Producer生产的消息,键-值对Message=Crc MagicByte Attributes Key Value名称名称类型类型描述描述CRCint32表示这条消息(不包括CRC字段本身)的校验码MagicByteint8表示消息格式的版本，用来做后向兼容，目前值为0Attributesint8表示这条消息的元数据，目前最低两位用来表示压缩格式Keybytes表示这条消息的Key，可以为nullValuebytes表示这条消息的Value。Kafka支持消息嵌套，也就是把一

31、条消息作为Value放到另外一条消息里面。Kafka的通讯协议的通讯协议MessageSet:用来组合多条Message，它在每条Message的基础上加上了Offset和MessageSizeMessageSet=Offset MessageSize Message名称名称类型类型描述描述Offsetint64它用来作为log中的序列号，Producer在生产消息的时候还不知道具体的值是什么，可以随便填个数字进去MessageSizeint32表示这条Message的大小Message-表示这条Message的具体内容，其格式见上一小节。Kafka的通讯协议组件关系的通讯协议组件关系Requ

32、est/Respone和Message/MessageSet的关系：备注：Kafka的通讯协议中不含Schema，格式也比较简单，这样设计的好处是协议自身的Overhead小，再加上把多条Message放在一起做压缩，提高压缩比率，从而在网络上传输的数据量会少一些。Request/Response是通讯层的结构，和网络的是通讯层的结构，和网络的7层模型对比的话，它类层模型对比的话，它类似于似于TCP层。层。Message/MessageSet定义的是业务层的结构，类似于网络7层模型中的HTTP层。Message/MessageSet只是Request/Response的payload中的一种数

33、据结构。Kafka的分布式实现的分布式实现 一个Topic的多个partitions,被分布在kafka集群中的多个server上;每个server(kafka实例)负责partitions中消息的读写操作;此外kafka还可以配置partitions需要备份的个数(replicas),每个partition将会被备份到多台机器上,以提高可用性;基于replicated方案,那么就意味着需要对多个备份进行调度;每个partition都有一个server为leader;leader负责所有的读写操作,如果leader失效,那么将会有其他follower来接管(成为新的leader);follow

34、er只是单调的和leader跟进,同步消息即可.由此可见作为leader的server承载了全部的请求压力,因此从集群的整体考虑,有多少个partitions就意味着有多少个leader;kafka会将leader均衡的分散在每个实例上,来确保整体的性能稳定.Kafka数据持久化数据持久化数据持久化：发现线性的访问磁盘，很多时候比随机的内存访问快得多传统的使用内存做为磁盘的缓存Kafka直接将数据写入到日志文件中日志数据持久化特性：写操作：通过将数据追加到文件中实现读操作：读的时候从文件中读就好了对比JVM特性：Java对象占用空间是非常大的，差不多是要存储的数据的两倍甚至更高随着堆中数据量的

35、增加，垃圾回收回变的越来越困难优势：读操作不会阻塞写操作和其他操作，数据大小不对性能产生影响；没有容量限制（相对于内存来说）的硬盘空间建立消息系统；线性访问磁盘，速度快，可以保存任意一段时间！Kafka安装安装下载http:/kafka.apache.org/downloads.html解压tar-zxvf kafka_2.10-0.8.1.1.tgz启动服务首先启动zookeeper服务bin/zookeeper-server-start.sh config/zookeeper.properties启动Kafkabin/kafka-server-start.sh config/server.

36、properties/dev/null 2&1&创建topic创建一个test的topic，一个分区一个副本bin/kafka-topics.sh-create-zookeeper localhost:2181-replication-factor 1-partitions 1-topic test查看主题bin/kafka-topics.sh-list-zookeeper localhost:2181查看主题详情bin/kafka-topics.sh-describe-zookeeper localhost:2181-topic test删除主题bin/kafka-topics.sh-zoo

37、keeper localhost:2181-delete-topic testKafka客户端操作客户端操作创建生产者 producerbin/kafka-console-producer.sh-broker-list localhost:9092-topic test 创建消费者 consumerbin/kafka-console-consumer.sh-zookeeper localhost:2181-topic test-from-beginning参数使用帮组信息查看：生产者参数查看：bin/kafka-console-producer.sh消费者参数查看：bin/kafka-cons

38、ole-consumer.shKafka多多broker部署部署修改config/service.propertiesbroker.id=0port=9020log.dirs=/tmp/kafka0-logs复制service.properties生成service1.propertiesbroker.id=1#id不能一样port=9040#port不能一样log.dirs=/tmp/kafka1-logs启动多个brokerbin/kafka-server-start.sh config/service.properties&bin/kafka-server-start.sh config

39、/service1.properties&创建主题bin/kafka-topics.sh-create-zookeeper localhost:2181-replication-factor 3-partitions 1-topic testkafka集群安装集群安装安装zk集群修改配置文件broker.id：唯一，填数字host.name：唯一，填服务器zookeeper.connect=192.168.40.134:2181,192.168.40.132:2181,192.168.40.133:2181Kafka的核心配置的核心配置server.properties配置详情见注释broke

40、r.id=work.threads=2num.io.threads=8socket.send.buffer.bytes=1048576socket.receive.buffer.bytes=1048576socket.request.max.bytes=104857600log.dirs=/tmp/kafka-logsnum.partitions=2log.retention.hours=168log.segment.bytes=536870912log.retention.check.interval.ms=60000log.cleaner.enable=falsezookeeper.con

41、nect=localhost:2181zookeeper.connection.timeout.ms=1000000Kafka的一致性的一致性MQ要实现从producer到consumer之间的可靠的消息传送和分发。传统的MQ系统通常都是通过broker和consumer间的确认（ack）机制实现的，并在broker保存消息分发的状态。即使这样一致性也是很难保证的（当然kafka也支持ack）。kafka保证一致性的做法是由 consumer自己保存状态，也不要任何确认。这样虽然consumer负担更重，但其实更灵活了。因为不管consumer上任何原因导致需要重新处 理消息，都可以再次从br

42、oker获得。Kafka的高可用性的高可用性Kafaka可以将log文件复制到其他topic的分隔点(可以看成是server)。当一个server在集群中fails，可以允许自动的failover到其他的复制的server，所以消息可以继续存在在这种情况下。Kafka的的zero-copy采用 linux Zero-Copy 提高发送性能。传统的数据发送需要发送 4 次上下文切换，采用 sendfile 系统调用之后，数据直接在内核态交换，系统上下文切换减少为 2 次。根据测试结果，可以提高 60%的数据发送性能。Kafka的的zero-copy 在Kafka上，有两个原因可能导致低效：1）太

43、多的网络请求 2）过多的字节拷贝。为了提高效率，Kafka把message分成一组一组的，每次请求会把一组message发给相应的consumer。此外，为了减少字节拷贝，采用了sendfile系统调用。为了理解sendfile原理，先说一下传统的利用socket发送文件要进行拷贝Sendfile系统调用Kafka的负载均衡的负载均衡Producer和broker之间没有负载均衡机制。负载均衡可以分为两个部分：producer发消息的负载均衡和consumer读消息的负载均衡。producer有一个到当前所有broker的连接池，当一个消息需要发送时，需要决定发到哪个broker（即parti

44、tion）。consumer读取消息时，除了考虑当前的broker情况外，还要考虑其他consumer的情况，才能决定从哪个partition读取消息。多个 partition 需要选取出 lead partition，lead partition 负责读写，broker和consumer之间利用zookeeper进行负载均衡。所有broker和consumer都会在zookeeper中进行注册，且 zookeeper会保存他们的一些元数据信息。如果某个broker和consumer发生了变化，所有其他的broker和consumer都会得到 通知。Kafka 可扩展性可扩展性当需要增加 br

45、oker 结点时，新增的 broker 会向 zookeeper 注册，而 producer 及 consumer 会根据注册在 zookeeper 上的 watcher 感知这些变化，并及时作出调整，这样就保证了添加或去除broker时，各broker间仍能自动实现负载均衡。Kafka的的Zookeeper协调控制协调控制1.管理broker与consumer的动态加入与离开。2.触发负载均衡，当broker或consumer加入或离开时会触发负载均衡算法，使得一个consumer group内的多个consumer的订阅负载平衡。3.维护消费关系及每个partion的消费信息。Zookee

46、per上的细节：1.每个broker启动后会在zookeeper上注册一个临时的broker registry，包含broker的ip地址和端口号，所存储的topics和partitions信息。2.每个consumer启动后会在zookeeper上注册一个临时的consumer registry：包含consumer所属的consumer group以及订阅的topics。3.每个consumer group关 联一个临时的owner registry和一个持久的offset registry。对于被订阅的每个partition包含一个owner registry，内容为订阅这个partit

47、ion的consumer id；同时包含一个offset registry，内容为上一次订阅的offset。kafka java操作操作生产者消费者pom依赖org.apache.kafkakafka_2.100.8.2.0Kafka 的应用场景的应用场景-消息队列消息队列 1.消息队列 比起大多数的消息系统来说，Kafka 有更好的吞吐量，内置的分区，冗余及容错性，这让 Kafka 成为了一个很好的大规模消息处理应用的解决方案。消息系统一般吞吐量相对较低，但是需要更小的端到端延时，并尝尝依赖于 Kafka 提供的强大的持久性保障。在这个领域，Kafka 足以媲美传统消息系统，如 Active

48、MR 或 RabbitMQ。Kafka 的应用场景的应用场景-行为跟踪行为跟踪 2.行为跟踪 Kafka 的另一个应用场景是跟踪用户浏览页面、搜索及其他行为，以发布-订阅的模式实时记录到对应的 topic 里。那么这些结果被订阅者拿到后，就可以做进一步的实时处理，或实时监控，或放到 hadoop/离线数据仓库里处理。Kafka 的应用场景的应用场景-元信息监控元信息监控 3.元信息监控 作为操作记录的监控模块来使用，即汇集记录一些操作信息，可以理解为运维性质的数据监控吧。Kafka 的应用场景的应用场景-日志收集日志收集 4.日志收集 日志收集方面，其实开源产品有很多，包括 Scribe、Ap

49、ache Flume。很多人使用 Kafka 代替日志聚合（log aggregation）。日志聚合一般来说是从服务器上收集日志文件，然后放到一个集中的位置（文件服务器或 HDFS）进行处理。然而 Kafka 忽略掉文件的细节，将其更清晰地抽象成一个个日志或事件的消息流。这就让 Kafka 处理过程延迟更低，更容易支持多数据源和分布式数据处理。比起以日志为中心的系统比如 Scribe 或者 Flume 来说，Kafka 提供同样高效的性能和因为复制导致的更高的耐用性保证，以及更低的端到端延迟。Kafka 的应用场景的应用场景-流处理流处理 5.流处理 这个场景可能比较多，也很好理解。保存收集

50、流数据，以提供之后对接的 Storm 或其他流式计算框架进行处理。很多用户会将那些从原始 topic 来的数据进行阶段性处理，汇总，扩充或者以其他的方式转换到新的 topic 下再继续后面的处理。例如一个文章推荐的处理流程，可能是先从 RSS 数据源中抓取文章的内容，然后将其丢入一个叫做“文章”的 topic 中；后续操作可能是需要对这个内容进行清理，比如回复正常数据或者删除重复数据，最后再将内容匹配的结果返还给用户。这就在一个独立的 topic 之外，产生了一系列的实时数据处理的流程。Strom 和 Samza 是非常著名的实现这种类型数据转换的框架。Kafka 的应用场景的应用场景-事件源事件源 6.事件源 事件源是一种应用程序设计的方式，该方式的状态转移被记录为按时间顺序排序的记录序列。Kafka 可以存储大量的日志数据，这使得它成为一个对这种方式的应用来说绝佳的后台。比如动态汇总（News feed）。Kafka 的应用场景的应用场景-持久性日志持久性日志 7.持久性日志（commit log）Kafka 可以为一种外部的持久性日志的分布式系统提供服务。这种日志可以在节点间备份数据，并为故障节点数据回复提供一种重新同步的机制。Kafka 中日志压缩功能为这种用法提供了条件。在这种用法中，Kafka 类似于 Apache BookKeeper 项目。