Kafka

官网： Apache Kafka http://kafka.apache.org/

kafka 简介

       kafka是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者规模的网站中的所有动作流数据。这种动作（网页浏览，搜索和其他用户的行动）是在现代网络上的许多社会功能的一个关键因素。这些数据通常是由于吞吐量的要求而通过处理日志和日志聚合来解决。

     Kafka是由Apache软件基金会开发的一个开源流处理平台，由Scala和Java编写。Kafka是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者规模的网站中的所有动作流数据。 这种动作（网页浏览，搜索和其他用户的行动）是在现代网络上的许多社会功能的一个关键因素。 这些数据通常是由于吞吐量的要求而通过处理日志和日志聚合来解决。 对于像Hadoop的一样的日志数据和离线分析系统，但又要求实时处理的限制，这是一个可行的解决方案。Kafka的目的是通过Hadoop的并行加载机制来统一线上和离线的消息处理，也是为了通过集群来提供实时的消息。

kafka 基础知识梳理

Kafka是分布式发布-订阅消息系统。它最初由LinkedIn公司开发，之后成为Apache项目的一部分。Kafka是一个分布式的，可划分的，冗余备份的持久性的日志服务。它主要用于处理活跃的流式数据。

在大数据系统中，常常会碰到一个问题，整个大数据是由各个子系统组成，数据需要在各个子系统中高性能，低延迟的不停流转。传统的企业消息系统并不是非常适合大规模的数据处理。为了已在同时搞定在线应用（消息）和离线应用（数据文件，日志）Kafka就出现了。Kafka可以起到两个作用：

1. 降低系统组网复杂度。
2. 降低编程复杂度，各个子系统不在是相互协商接口，各个子系统类似插口插在插座上，Kafka承担高速数据总线的作用。

Kafka主要特点：

1. 同时为发布和订阅提供高吞吐量。据了解，Kafka每秒可以生产约25万消息（50 MB），每秒处理55万消息（110 MB）。
2. 可进行持久化操作。将消息持久化到磁盘，因此可用于批量消费，例如ETL，以及实时应用程序。通过将数据持久化到硬盘以及replication防止数据丢失。
3. 分布式系统，易于向外扩展。所有的producer、broker和consumer都会有多个，均为分布式的。无需停机即可扩展机器。
4. 消息被处理的状态是在consumer端维护，而不是由server端维护。当失败时能自动平衡。
5. 支持online和offline的场景。

kafka应用场景：
       构建实时的流数据管道，可靠地获取系统和应用程序之间的数据。
       构建实时流的应用程序，对数据流进行转换或反应。

 kafka基基原理:

       通常来讲，消息模型可以分为两种：队列和发布-订阅式。队列的处理方式是一组消费者从服务器读取消息，一条消息只有其中的一个消费者来处理。在发布-订阅模型中，消息被广播给所有的消费者，接收到消息的消费者都可以处理此消息。Kafka为这两种模型提供了单一的消费者抽象模型： 消费者组(consumer group)。消费者用一个消费者组名标记自己。

       一个发布在Topic上消息被分发给此消费者组中的一个消费者。假如所有的消费者都在一个组中，那么这就变成了queue模型。假如所有的消费者都在不同的组中，那么就完全变成了发布-订阅模型。更通用的， 我们可以创建一些消费者组作为逻辑上的订阅者。每个组包含数目不等的消费者，一个组内多个消费者可以用来扩展性能和容错。       

       并且，kafka能够保证生产者发送到一个特定的Topic的分区上，消息将会按照它们发送的顺序依次加入，也就是说，如果一个消息M1和M2使用相同的producer发送，M1先发送，那么M1将比M2的offset低，并且优先的出现在日志中。消费者收到的消息也是此顺序。如果一个Topic配置了复制因子（replication facto）为N,那么可以允许N-1服务器宕机而不丢失任何已经提交（committed）的消息。此特性说明kafka有比传统的消息系统更强的顺序保证。但是，相同的消费者组中不能有比分区更多的消费者，否则多出的消费者一直处于空等待，不会收到消息。

                                                                    Kafka的架构：

kafka名词解释

• producer：生产者。
• consumer：消费者。
• topic: 消息以topic为类别记录,Kafka将消息种子(Feed)分门别类,每一类的消息称之为一个主题(Topic)。
• broker：以集群的方式运行,可以由一个或多个服务组成，每个服务叫做一个broker;消费者可以订阅一个或多个主题(topic),并从Broker拉数据,从而消费这些已发布的消息。

      每个消息（也叫作record记录,也被称为消息）是由一个key，一个value和时间戳构成。

kafka有四个核心API介绍

• 应用程序使用producer API发布消息到1个或多个topic中。
• 应用程序使用consumer API来订阅一个或多个topic,并处理产生的消息。
• 应用程序使用streams API充当一个流处理器,从1个或多个topic消费输入流,并产生一个输出流到1个或多个topic,有效地将输入流转换到输出流。
• connector API允许构建或运行可重复使用的生产者或消费者,将topic链接到现有的应用程序或数据系统。 

Kafka的整体架构非常简单，是显式分布式架构，producer、broker（kafka）和consumer都可以有多个。Producer，consumer实现Kafka注册的接口，数据从producer发送到broker，broker承担一个中间缓存和分发的作用。broker分发注册到系统中的consumer。broker的作用类似于缓存，即活跃的数据和离线处理系统之间的缓存。客户端和服务器端的通信，是基于简单，高性能，且与编程语言无关的TCP协议。几个基本概念：

1. Topic：特指Kafka处理的消息源（feeds of messages）的不同分类。
2. Partition：Topic物理上的分组，一个topic可以分为多个partition，每个partition是一个有序的队列。partition中的每条消息都会被分配一个有序的id（offset）。
3. Message：消息，是通信的基本单位，每个producer可以向一个topic（主题）发布一些消息。
4. Producers：消息和数据生产者，向Kafka的一个topic发布消息的过程叫做producers。
5. Consumers：消息和数据消费者，订阅topics并处理其发布的消息的过程叫做consumers。
6. Broker：缓存代理，Kafka集群中的一台或多台服务器统称为broker。

                                                             消息发送的流程：

1. Producer根据指定的partition方法（round-robin、hash等），将消息发布到指定topic的partition里面
2. kafka集群接收到Producer发过来的消息后，将其持久化到硬盘，并保留消息指定时长（可配置），而不关注消息是否被消费。
3. Consumer从kafka集群pull数据，并控制获取消息的offset

Kafka的设计：

1、吞吐量

高吞吐是kafka需要实现的核心目标之一，为此kafka做了以下一些设计：

1. 数据磁盘持久化：消息不在内存中cache，直接写入到磁盘，充分利用磁盘的顺序读写性能
2. zero-copy：减少IO操作步骤
3. 数据批量发送
4. 数据压缩
5. Topic划分为多个partition，提高parallelism

负载均衡

1. producer根据用户指定的算法，将消息发送到指定的partition
2. 存在多个partiiton，每个partition有自己的replica，每个replica分布在不同的Broker节点上
3. 多个partition需要选取出lead partition，lead partition负责读写，并由zookeeper负责fail over
4. 通过zookeeper管理broker与consumer的动态加入与离开

拉取系统

由于kafka broker会持久化数据，broker没有内存压力，因此，consumer非常适合采取pull的方式消费数据，具有以下几点好处：

1. 简化kafka设计
2. consumer根据消费能力自主控制消息拉取速度
3. consumer根据自身情况自主选择消费模式，例如批量，重复消费，从尾端开始消费等

可扩展性

当需要增加broker结点时，新增的broker会向zookeeper注册，而producer及consumer会根据注册在zookeeper上的watcher感知这些变化，并及时作出调整。

Kafka的应用场景：

1.消息队列

比起大多数的消息系统来说，Kafka有更好的吞吐量，内置的分区，冗余及容错性，这让Kafka成为了一个很好的大规模消息处理应用的解决方案。消息系统一般吞吐量相对较低，但是需要更小的端到端延时，并常常依赖于Kafka提供的强大的持久性保障。在这个领域，Kafka足以媲美传统消息系统，如ActiveMR或RabbitMQ。

2.行为跟踪

Kafka的另一个应用场景是跟踪用户浏览页面、搜索及其他行为，以发布-订阅的模式实时记录到对应的topic里。那么这些结果被订阅者拿到后，就可以做进一步的实时处理，或实时监控，或放到hadoop/离线数据仓库里处理。

3.元信息监控

作为操作记录的监控模块来使用，即汇集记录一些操作信息，可以理解为运维性质的数据监控吧。

4.日志收集

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

5.流处理

这个场景可能比较多，也很好理解。保存收集流数据，以提供之后对接的Storm或其他流式计算框架进行处理。很多用户会将那些从原始topic来的数据进行阶段性处理，汇总，扩充或者以其他的方式转换到新的topic下再继续后面的处理。例如一个文章推荐的处理流程，可能是先从RSS数据源中抓取文章的内容，然后将其丢入一个叫做“文章”的topic中；后续操作可能是需要对这个内容进行清理，比如回复正常数据或者删除重复数据，最后再将内容匹配的结果返还给用户。这就在一个独立的topic之外，产生了一系列的实时数据处理的流程。Strom和Samza是非常著名的实现这种类型数据转换的框架。

6.事件源

事件源是一种应用程序设计的方式，该方式的状态转移被记录为按时间顺序排序的记录序列。Kafka可以存储大量的日志数据，这使得它成为一个对这种方式的应用来说绝佳的后台。比如动态汇总（News feed）。

7.持久性日志（commit log）

Kafka可以为一种外部的持久性日志的分布式系统提供服务。这种日志可以在节点间备份数据，并为故障节点数据回复提供一种重新同步的机制。Kafka中日志压缩功能为这种用法提供了条件。在这种用法中，Kafka类似于Apache BookKeeper项目。

Kafka的设计要点：

1、直接使用linux 文件系统的cache，来高效缓存数据。

2、采用linux Zero-Copy提高发送性能。传统的数据发送需要发送4次上下文切换，采用sendfile系统调用之后，数据直接在内核态交换，系统上下文切换减少为2次。根据测试结果，可以提高60%的数据发送性能。Zero-Copy详细的技术细节可以参考：https://www.ibm.com/developerworks/linux/library/j-zerocopy/

3、数据在磁盘上存取代价为O(1)。kafka以topic来进行消息管理，每个topic包含多个part（ition），每个part对应一个逻辑log，有多个segment组成。每个segment中存储多条消息（见下图），消息id由其逻辑位置决定，即从消息id可直接定位到消息的存储位置，避免id到位置的额外映射。每个part在内存中对应一个index，记录每个segment中的第一条消息偏移。发布者发到某个topic的消息会被均匀的分布到多个part上（随机或根据用户指定的回调函数进行分布），broker收到发布消息往对应part的最后一个segment上添加该消息，当某个segment上的消息条数达到配置值或消息发布时间超过阈值时，segment上的消息会被flush到磁盘，只有flush到磁盘上的消息订阅者才能订阅到，segment达到一定的大小后将不会再往该segment写数据，broker会创建新的segment。

4、显式分布式，即所有的producer、broker和consumer都会有多个，均为分布式的。Producer和broker之间没有负载均衡机制。broker和consumer之间利用zookeeper进行负载均衡。所有broker和consumer都会在zookeeper中进行注册，且zookeeper会保存他们的一些元数据信息。如果某个broker和consumer发生了变化，所有其他的broker和consumer都会得到通知。

一. Concepts

Kafka is used for building real-time data pipelines and streaming apps

• 分布式消息传递
• 网站活跃数据跟踪
• 日志聚合
• 流式数据处理
• 数据存储
• 事件源
• ……

Kafka terminology 术语

1.Topics

Kafka maintains feeds of messages in categories called topics. 
消息都归属于一个类别成为topic,在物理上不同Topic的消息分开存储,逻辑上一个Topic的消息对使用者透明 

2.Partitions

Topics are broken up into ordered commit logs called partitions 
每个Topics划分为一个或者多个Partition,并且Partition中的每条消息都被标记了一个sequential id ,也就是offset,并且存储的数据是可配置存储时间的 

3.Message Ordering

消息只保证在同一个Partition中有序,所以,如果要保证从Topic中拿到的数据有序,则需要做到:

• Group messages in a partition by key(producer)
• Configure exactly one consumer instance per partition within a consumer group

kafka能保证的是:

• Message sent by a producer to a particular topic partition will be appended in the order they are sent
• A consumer instance sees messages in the order they are stored in the log
• For a topic with replication factor N, kafka can tolerate up to N-1 server failures without “losing” any messages committed to the log

4.Log

Partition对应逻辑上的Log

5.Replication 副本

• Topics can (and should) be replicated
• The unit of replication is the partition
• Each partition in a topic has 1 leader and 0 or more replicas

• A replica is deemed to be “in-sync” if

  • The replica can communicate with Zookeeper
  • The replica is not “too far” behind the leader(configurable)

• The group of in-sync replicas for a partition is called the ISR(In-Sync-Replicas)

• The Replication factor cannot be lowered

6.kafka durability 可靠性

Durability can be configured with the producer configuration request.required.acks

• 0 : The producer never waits for an ack
• 1 : The producer gets an ack after the leader replica has received the data
• -1 : The producer gets an ack after all ISRs receive the data

Minimum available ISR can also be configured such that an error is returned if enough replicas are not available to replicate data

所以,kafka可以选择不同的durability来换取不同的吞吐量

Durability	Behaviour	Per Event Latency	Required Acknowledgements(request.required.acks)
Hignest	ACK all ISRs have received	Higest	-1
Medium	ACK once the leader has received	Medium	1
Lowest	No ACKs required	Lowest	0

通用,kafka可以通过增加更多的Broker来提升吞吐量 
一个推荐的配置:

Property	Value
replication	3
min.insync.replicas	2
request.required.acks	-1

7.Broker

Kafka is run as a cluster comparised of one or more servers each of which is called broker 

8.Producer

Processes that publish messages to a kafka topic are called producers

• Producers publish to a topic of their choosing(push) 
  数据载入kafka可以是分布式的,通常是通过”Round-Robin”算法策略,也可以根据message中的key来进行语义分割”semantic partitioning”来分布式载入,Brokers 通过分区来均衡载入
• kafka支持异步发送async,异步发送消息是less durable的,但是是高吞吐的
• Producer的载入平衡和ISRs 
  

9.Consumer

Processes that subscribe(订阅) to tpics and process the feed of published messages are called consumers

• Multiple Consumer can read from the same topic
• Each Consumer is responsible for managing it’s own offset
• Message stay on kafka… they are not removed after they consumed 
  

Consumer可以从任一地方开始消费,然后又回到最大偏移量处,Consumers又可以被划分为Consumer Group

10.Consumer Group

Consumer Group是显式分布式,多个Consumer构成组结构,Message只能传输给某个Group中的某一个Consumer

• 常用的Consumer Group模式:

  • All consumer instances in one group 
    Acts like a traditional queue with load balancing
  • All consumer instances in different groups 
    All messages are broadcast to all consumer instances
  • “Logical Subscriber” - Many consumer instances in a group 
    Consumers are added for scalability and fault tolerance,Each consumer instance reads from one or more partitions for a topic ,There cannot be more consumer instances than partitions

 
Consumer Groups 提供了topics和partitions的隔离 
 
并且当某个Consumer挂掉后能够重新平衡

• Consumer Group的应用场景

  • 点对点 
    将所有消费者放到一个Consumer Group
  • 广播 
    将每个消费者单独放到一个Consumer Group
  • 水平扩展 
    向Consumer Group中添加消费者并进行Rebalance
  • 故障转移 
    当某个Consumer发生故障时,Consumer Group重新分配分区

二. Kafka 核心原理

Kafka设计思想

• 可持久化Message 
  持久化本地文件系统,设置有效期
• 支持高流量处理 
  面向特定的使用场景而不是通用功能
• 消费状态保存在消费端而不是服务端 
  减轻服务器负担和交互
• 支持分布式 
  生产者/消费者透明异步
• 依赖磁盘文件系统做消息缓存 
  不消耗内存
• 高效的磁盘存取 
  复杂度为O(1)
• 强调减少数据的序列化和拷贝开销 
  批量存储和发送、zero-copy
• 支持数据并行加载到Hadoop 
  集成Hadoop

Kafka原理分析

1.存储

• Partition 
  topic物理上的分组，一个topic可以分为多个partition，每个partition是一个有序的队列。 
  在Kafka文件存储中，同一个topic下有多个不同partition，每个partition为一个目录，partiton命名规则为topic名称+有序序号，第一个partiton序号从0开始，序号最大值为partitions数量减1 
   
  每个partion(目录)相当于一个巨型文件被平均分配到多个大小相等segment(段)数据文件中。但每个段segment file消息数量不一定相等，这种特性方便old segment file快速被删除。 
  每个partiton只需要支持顺序读写就行了，segment文件生命周期由服务端配置参数决定。 
  这样做的好处就是能快速删除无用文件，有效提高磁盘利用率。

• segment file

  • segment file组成：由2大部分组成，分别为index file和data file，此2个文件一一对应，成对出现，后缀”.index”和“.log”分别表示为segment索引文件、数据文件.
  • segment文件命名规则：partion全局的第一个segment从0开始，后续每个segment文件名为上一个segment文件最后一条消息的offset值。数值最大为64位long大小，19位数字字符长度，没有数字用0填充。

 
其中.index索引文件存储大量元数据，.log数据文件存储大量消息，索引文件中元数据指向对应数据文件中message的物理偏移地址。他们两个是一一对应的,对应关系如下 

• Message 
  segment data file由许多message组成，message物理结构如下 
  

参数说明:

关键字	解释说明
8 byte offset	在parition(分区)内的每条消息都有一个有序的id号，这个id号被称为偏移(offset),它可以唯一确定每条消息在parition(分区)内的位置。即offset表示partiion的第多少message
4 byte message size	message大小
4 byte CRC32	用crc32校验message
1 byte “magic”	表示本次发布Kafka服务程序协议版本号
1 byte “attributes”	表示为独立版本、或标识压缩类型、或编码类型。
4 byte key length	表示key的长度,当key为-1时，K byte key字段不填
K byte key	可选
value bytes payload	表示实际消息数据。

2. Consumer

• High Level Consumer 
  消费者保存消费状态：将从某个Partition读取的最后一条消息的offset存于ZooKeeper中
• Low Level Consumer：更好的控制数据的消费 
  同一条消息读多次 
  只读取某个Topic的部分Partition 
  管理事务，从而确保每条消息被处理一次，且仅被处理一次 
  大量额外工作 
  必须在应用程序中跟踪offset，从而确定下一条应该消费哪条消息 
  应用程序需要通过程序获知每个Partition的Leader是谁 
  必须处理Leader的变化

3.消息传递语义Delivery Semantics

• At least once 
  kafka的默认设置 
  Messages are never lost but maybe redelivered
• At most once 
  Messages are lost but never redelivered
• Exactly once 
  比较难实现 
  Messages are delivered once and only once 
  实现Exactly Once需要考虑: 
  • Must consider two components 
    Durability guarantees when publishing a message 
    Durability guarantees when consuming a message
  • Producer 
    What happens when a produce request was sent but a network error returned before an ack ? 
    RE:Use a single writer per partition and check the latest committed value after network errors
• Consumer 
  include a unique ID(e.g.UUID) and de-duplicate 
  Consider storing offsets with data

解释:

• 消息传递语义: Producer 角度 
  当Producer向broker发送消息时，一旦这条消息被commit，因为replication的存在，它就不会丢,但是如果Producer发送数据给broker后，遇到网络问题而造成通信中断，那Producer就无法判断该条消息是否已经commit 
  理想的解决方案：Producer可以生成一种类似于主键的东西，发生故障时幂等性的重试多次，这样就做到了Exactly once,目前默认情况下一条消息从Producer到broker是确保了At least once

• 消息传递语义: Consumer : High Level API 
  Consumer在从broker读取消息后，可以选择commit，该操作会在Zookeeper中保存该Consumer在该Partition中读取的消息的offset 
  该Consumer下一次再读该Partition时会从下一条开始读取；如未commit，下一次读取的开始位置会跟上一次commit之后的开始位置相同 
  现实的问题：到底是先处理消息再commit，还是先commit再处理消息？

  • 先处理消息再commit 
    如果在处理完消息再进行commit之前Consumer发生宕机，下次重新开始工作时还会处理刚刚未commit的消息，实际上该消息已经被处理过了。这就对应于At least once 
    业务场景使用幂等性：消息都有一个主键，所以消息的处理往往具有幂等性，即多次处理这一条消息跟只处理一次是等效的，那就可以认为是Exactly once。
  • 先commit再处理消息 
    如果Consumer在commit后还没来得及处理消息就宕机了，下次重新开始工作后就无法读到刚刚已提交而未处理的消息，这就对应于At most once

• 消息传递语义: Consumer : Lower Level API 
  Exactly once的实现思想：协调offset和消息数据 
  经典做法是引入两阶段提交 
  offset和消息数据放在同一个地方：Consumer拿到数据后可能把数据放到共享空间中，如果把最新的offset和数据本身一起写到共享空间，那就可以保证数据的输出和offset的更新要么都完成，要么都不完成，间接实现Exactly once 
  High level API而言，offset是存于Zookeeper中的，无法获取，而Low level API的offset是由自己去维护的，可以实现以上方案

4.高可用性

同一个Partition可能会有多个Replica，需要保证同一个Partition的多个Replica之间的数据一致性 
而这时需要在这些Replication之间选出一个Leader，Producer和Consumer只与这个Leader交互，其它Replica作为Follower从Leader中复制数据

• 副本与高可用性：副本Leader Election算法

  • Zookeeper中的选举算法回顾 
    少数服从多数：确保集群中一半以上的机器得到同步 
    适合共享集群配置的系统中，而并不适合需要存储大量数据的系统，因为需要大量副本集。f个Replica失败情况下需要2f+1个副本
  • Kafka的做法 
    ISR(in-sync replicas)，这个ISR里的所有副本都跟上了Leader，只有ISR里的成员才有被选为Leader的可能 
    在这种模式下，对于f+1个副本，一个Partition能在保证不丢失已经commit的消息的前提下容忍f个副本的失败 
    ISR需要的总的副本的个数几乎是“少数服从多数”的一半

• 副本与高可用性：Replica分配算法 
  将所有Replica均匀分布到整个集群 
  将所有n个Broker和待分配的Partition排序 
  将第i个Partition分配到第(i mod n)个Broker上 
  将第i个Partition的第j个Replica分配到第((i + j) mode n)个Broker上

5. 零拷贝

Kafka通过Message分组和Sendfile系统调用实现了zero-copy

• 传统的socket发送文件拷贝 
   
  1.内核态 
  2.用户态 
  3.内核态 
  4.网卡缓存 
  经历了内核态和用户态的拷贝

• sendfile系统调用 
   
  避免了内核态与用户态的上下文切换动作

sendfile 
优点：大块文件传输效率高 
缺点：小块文件效率较低、BIO而不是NIO 
mmap+write 
优点：使用小块文件传输时效率高 
缺点：比sendfile多消耗CPU、内存安全控制复杂 
应用 
Kafka使用第一种，大块数据传输 
RocketMQ使用第二种，小快数据传输

三. Use Cases

• Real-Time Stream Processing(combined with Spark Streaming)
• General purpose Message Bus
• Collecting User Activity Data
• Collecting Operational Metrics from applications,servers or devices
• Log Aggregation
• Change Data Capture
• Commit Log for distributed systems

四. Development with Kafka

五. Administration

• list && describe

echo "此Kafka集群所有的Topic : "
kafka-topics --list --zookeeper dc226.dooioo.cn:2181, dc227.dooioo.cn:2181,dc229.dooioo.cn:2181/kafka

echo "您要查看的Topic详细 : "

kafka-topics --describe --zookeeper dc226.dooioo.cn:2181, dc227.dooioo.cn:2181,dc229.dooioo.cn:2181/kafka --topic $topicName

• create topic

kafka-topics --create --zookeeper dc226.dooioo.cn:2181,dc227.dooioo.cn:2181,dc229.dooioo.cn:2181/kafka --replication-factor 1 --pa
rtitions 1 --topic $topicName

• open producer

kafka-console-producer --broker-list 10.22.253.227:9092 --topic $topicName 

• open consumer

kafka-console-consumer --zookeeper 10.22.253.226:2181,10.22.253.227:2181,10.22.253.229:2181/kafka --topic $topicName --from-beginning

六. Cluster Planning

七. Compare

 

更多理论知识：Kafka史上最详细原理总结  https://blog.csdn.net/ychenfeng/article/details/74980531

参考资料：

• Apache Kafka网站
• 项目设计讨论
• Github镜像
• Morten Kjetland对Apache Kafka的介绍
• Quora上与RabbitMQ的对比
• Kafka: a Distributed Messaging System for Log Processing
• Zero-copy原理
• Kafka与Hadoop
• kafka实战 https://www.cnblogs.com/hei12138/p/7805475.html
• kafka 基础知识梳理  https://www.cnblogs.com/yangxiaoyi/p/7359236.html