【干货】Kafka深度解析

原创文章，转载请务必将下面这段话置于文章开头处。 本文转发自Jason’s Blog，原文链接 http://www.jasongj.com/2015/01/02/Kafka深度解析

背景介绍

Kafka简介

Kafka是一种分布式的，基于发布/订阅的消息系统。主要设计目标如下：

• 以时间复杂度为O(1)的方式提供消息持久化能力，即使对TB级以上数据也能保证常数时间的访问性能
• 高吞吐率。即使在非常廉价的商用机器上也能做到单机支持每秒100K条消息的传输
• 支持Kafka Server间的消息分区，及分布式消费，同时保证每个partition内的消息顺序传输
• 同时支持离线数据处理和实时数据处理

为什么要用消息系统

• 解耦
  在项目启动之初来预测将来项目会碰到什么需求，是极其困难的。消息队列在处理过程中间插入了一个隐含的、基于数据的接口层，两边的处理过程都要实现这一接口。这允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束
• 冗余
  有些情况下，处理数据的过程会失败。除非数据被持久化，否则将造成丢失。消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险。在被许多消息队列所采用的”插入-获取-删除”范式中，在把一个消息从队列中删除之前，需要你的处理过程明确的指出该消息已经被处理完毕，确保你的数据被安全的保存直到你使用完毕。
• 扩展性
  因为消息队列解耦了你的处理过程，所以增大消息入队和处理的频率是很容易的；只要另外增加处理过程即可。不需要改变代码、不需要调节参数。扩展就像调大电力按钮一样简单。
• 灵活性 & 峰值处理能力
  在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量并不常见；如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃。
• 可恢复性
  当体系的一部分组件失效，不会影响到整个系统。消息队列降低了进程间的耦合度，所以即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。而这种允许重试或者延后处理请求的能力通常是造就一个略感不便的用户和一个沮丧透顶的用户之间的区别。
• 送达保证
  消息队列提供的冗余机制保证了消息能被实际的处理，只要一个进程读取了该队列即可。在此基础上，IronMQ提供了一个”只送达一次”保证。无论有多少进程在从队列中领取数据，每一个消息只能被处理一次。这之所以成为可能，是因为获取一个消息只是”预定”了这个消息，暂时把它移出了队列。除非客户端明确的表示已经处理完了这个消息，否则这个消息会被放回队列中去，在一段可配置的时间之后可再次被处理。

• 顺序保证
  在大多使用场景下，数据处理的顺序都很重要。消息队列本来就是排序的，并且能保证数据会按照特定的顺序来处理。IronMO保证消息通过FIFO（先进先出）的顺序来处理，因此消息在队列中的位置就是从队列中检索他们的位置。
• 缓冲
  在任何重要的系统中，都会有需要不同的处理时间的元素。例如,加载一张图片比应用过滤器花费更少的时间。消息队列通过一个缓冲层来帮助任务最高效率的执行–写入队列的处理会尽可能的快速，而不受从队列读的预备处理的约束。该缓冲有助于控制和优化数据流经过系统的速度。
• 理解数据流
  在一个分布式系统里，要得到一个关于用户操作会用多长时间及其原因的总体印象，是个巨大的挑战。消息队列通过消息被处理的频率，来方便的辅助确定那些表现不佳的处理过程或领域，这些地方的数据流都不够优化。
• 异步通信
  很多时候，你不想也不需要立即处理消息。消息队列提供了异步处理机制，允许你把一个消息放入队列，但并不立即处理它。你想向队列中放入多少消息就放多少，然后在你乐意的时候再去处理它们。

常用Message Queue对比

• RabbitMQ
  RabbitMQ是使用Erlang编写的一个开源的消息队列，本身支持很多的协议：AMQP，XMPP, SMTP, STOMP，也正因如此，它非常重量级，更适合于企业级的开发。同时实现了Broker构架，这意味着消息在发送给客户端时先在中心队列排队。对路由，负载均衡或者数据持久化都有很好的支持。
• Redis
  Redis是一个基于Key-Value对的NoSQL数据库，开发维护很活跃。虽然它是一个Key-Value数据库存储系统，但它本身支持MQ功能，所以完全可以当做一个轻量级的队列服务来使用。对于RabbitMQ和Redis的入队和出队操作，各执行100万次，每10万次记录一次执行时间。测试数据分为128Bytes、512Bytes、1K和10K四个不同大小的数据。实验表明：入队时，当数据比较小时Redis的性能要高于RabbitMQ，而如果数据大小超过了10K，Redis则慢的无法忍受；出队时，无论数据大小，Redis都表现出非常好的性能，而RabbitMQ的出队性能则远低于Redis。
• ZeroMQ
  ZeroMQ号称最快的消息队列系统，尤其针对大吞吐量的需求场景。ZMQ能够实现RabbitMQ不擅长的高级/复杂的队列，但是开发人员需要自己组合多种技术框架，技术上的复杂度是对这MQ能够应用成功的挑战。ZeroMQ具有一个独特的非中间件的模式，你不需要安装和运行一个消息服务器或中间件，因为你的应用程序将扮演了这个服务角色。你只需要简单的引用ZeroMQ程序库，可以使用NuGet安装，然后你就可以愉快的在应用程序之间发送消息了。但是ZeroMQ仅提供非持久性的队列，也就是说如果宕机，数据将会丢失。其中，Twitter的Storm 0.9.0以前的版本中默认使用ZeroMQ作为数据流的传输（Storm从0.9版本开始同时支持ZeroMQ和Netty作为传输模块）。
• ActiveMQ
  ActiveMQ是Apache下的一个子项目。 类似于ZeroMQ，它能够以代理人和点对点的技术实现队列。同时类似于RabbitMQ，它少量代码就可以高效地实现高级应用场景。
• Kafka/Jafka
  Kafka是Apache下的一个子项目，是一个高性能跨语言分布式发布/订阅消息队列系统，而Jafka是在Kafka之上孵化而来的，即Kafka的一个升级版。具有以下特性：快速持久化，可以在O(1)的系统开销下进行消息持久化；高吞吐，在一台普通的服务器上既可以达到10W/s的吞吐速率；完全的分布式系统，Broker、Producer、Consumer都原生自动支持分布式，自动实现负载均衡；支持Hadoop数据并行加载，对于像Hadoop的一样的日志数据和离线分析系统，但又要求实时处理的限制，这是一个可行的解决方案。Kafka通过Hadoop的并行加载机制来统一了在线和离线的消息处理。Apache Kafka相对于ActiveMQ是一个非常轻量级的消息系统，除了性能非常好之外，还是一个工作良好的分布式系统。

Kafka解析

Terminology

• Broker
  Kafka集群包含一个或多个服务器，这种服务器被称为broker
• Topic
  每条发布到Kafka集群的消息都有一个类别，这个类别被称为topic。（物理上不同topic的消息分开存储，逻辑上一个topic的消息虽然保存于一个或多个broker上但用户只需指定消息的topic即可生产或消费数据而不必关心数据存于何处）
• Partition
  parition是物理上的概念，每个topic包含一个或多个partition，创建topic时可指定parition数量。每个partition对应于一个文件夹，该文件夹下存储该partition的数据和索引文件
• Producer
  负责发布消息到Kafka broker
• Consumer
  消费消息。每个consumer属于一个特定的consumer group（可为每个consumer指定group name，若不指定group name则属于默认的group）。使用consumer high level API时，同一topic的一条消息只能被同一个consumer group内的一个consumer消费，但多个consumer group可同时消费这一消息。

Kafka架构

Push vs. Pull

Topic & Partition

 <span class="line"><span class="comment"># The default number of log partitions per topic. More partitions allow greater</span></span> <span class="line"><span class="comment"># parallelism for consumption, but this will also result in more files across</span></span> <span class="line"><span class="comment"># the brokers.</span></span> <span class="line">num.partitions=<span class="number">3</span></span>1234<spanclass="line"><spanclass="comment"># The default number of log partitions per topic. More partitions allow greater</span></span><spanclass="line"><spanclass="comment"># parallelism for consumption, but this will also result in more files across</span></span><spanclass="line"><spanclass="comment"># the brokers.</span></span><spanclass="line">num.partitions=<spanclass="number">3</span></span> 

在发送一条消息时，可以指定这条消息的key，producer根据这个key和partition机制来判断将这条消息发送到哪个parition。paritition机制可以通过指定producer的paritition. class这一参数来指定，该class必须实现 kafka.producer.Partitioner 接口。本例中如果key可以被解析为整数则将对应的整数与partition总数取余，该消息会被发送到该数对应的partition。（每个parition都会有个序号）

 <span class="line"><span class="keyword">import</span> kafka.producer.Partitioner;</span> <span class="line"><span class="keyword">import</span> kafka.utils.VerifiableProperties;</span> <span class="line"><span class="keyword">public</span> <span class="class"><span class="keyword">class</span> <span class="title">JasonPartitioner</span><<span class="title">T</span>> <span class="keyword">implements</span> <span class="title">Partitioner</span> </span>{</span> <span class="line"> <span class="function"><span class="keyword">public</span> <span class="title">JasonPartitioner</span><span class="params">(VerifiableProperties verifiableProperties)</span> </span>{}</span> <span class="line"> <span class="annotation">@Override</span></span> <span class="line"> <span class="function"><span class="keyword">public</span> <span class="keyword">int</span> <span class="title">partition</span><span class="params">(Object key, <span class="keyword">int</span> numPartitions)</span> </span>{</span> <span class="line"> <span class="keyword">try</span> {</span> <span class="line"> <span class="keyword">int</span> partitionNum = Integer.parseInt((String) key);</span> <span class="line"> <span class="keyword">return</span> Math.abs(Integer.parseInt((String) key) % numPartitions);</span> <span class="line"> } <span class="keyword">catch</span> (Exception e) {</span> <span class="line"> <span class="keyword">return</span> Math.abs(key.hashCode() % numPartitions);</span> <span class="line"> }</span> <span class="line"> }</span> <span class="line">}</span> <span class="line"> </span> <span class="line"> 如果将上例中的<span class="class"><span class="keyword">class</span>作为<span class="title">partition</span>.<span class="title">class</span>，并通过如下代码发送20条消息（<span class="title">key</span>分别为0，1，2，3）至<span class="title">topic2</span>（包含4个<span class="title">partition</span>）。</span> <span class="line"> </span> <span class="line"><span class="title">public</span> <span class="title">void</span> <span class="title">sendMessage</span>() <span class="title">throws</span> <span class="title">InterruptedException</span></span>{</span> <span class="line"> <span class="keyword">for</span>(<span class="keyword">int</span> i = <span class="number">1</span>; i <= <span class="number">5</span>; i++){</span> <span class="line"> List messageList = <span class="keyword">new</span> ArrayList<KeyedMessage<String, String>>();</span> <span class="line"> <span class="keyword">for</span>(<span class="keyword">int</span> j = <span class="number">0</span>; j < <span class="number">4</span>; j++）{</span> <span class="line"> messageList.add(<span class="keyword">new</span> KeyedMessage<String, String>(<span class="string">"topic2"</span>, j+<span class="string">""</span>, <span class="string">"The "</span> + i + <span class="string">" message for key "</span> + j));</span> <span class="line"> }</span> <span class="line"> producer.send(messageList);</span> <span class="line"> }</span> <span class="line"> producer.close();</span> <span class="line">}</span>12345678910111213141516171819202122232425262728293031<spanclass="line"><spanclass="keyword">import</span>kafka.producer.Partitioner;</span><spanclass="line"><spanclass="keyword">import</span>kafka.utils.VerifiableProperties;</span> <spanclass="line"><spanclass="keyword">public</span><spanclass="class"><spanclass="keyword">class</span><spanclass="title">JasonPartitioner</span><<spanclass="title">T</span>><spanclass="keyword">implements</span><spanclass="title">Partitioner</span></span>{</span> <spanclass="line">    <spanclass="function"><spanclass="keyword">public</span><spanclass="title">JasonPartitioner</span><spanclass="params">(VerifiablePropertiesverifiableProperties)</span></span>{}</span>    <spanclass="line">    <spanclass="annotation">@Override</span></span><spanclass="line">    <spanclass="function"><spanclass="keyword">public</span><spanclass="keyword">int</span><spanclass="title">partition</span><spanclass="params">(Objectkey,<spanclass="keyword">int</span>numPartitions)</span></span>{</span><spanclass="line">        <spanclass="keyword">try</span>{</span><spanclass="line">            <spanclass="keyword">int</span>partitionNum=Integer.parseInt((String)key);</span><spanclass="line">            <spanclass="keyword">return</span>Math.abs(Integer.parseInt((String)key)%numPartitions);</span><spanclass="line">        }<spanclass="keyword">catch</span>(Exceptione){</span><spanclass="line">            <spanclass="keyword">return</span>Math.abs(key.hashCode()%numPartitions);</span><spanclass="line">        }</span><spanclass="line">    }</span><spanclass="line">}</span><spanclass="line"></span><spanclass="line">如果将上例中的<spanclass="class"><spanclass="keyword">class</span>作为<spanclass="title">partition</span>.<spanclass="title">class</span>，并通过如下代码发送20条消息（<spanclass="title">key</span>分别为0，1，2，3）至<spanclass="title">topic2</span>（包含4个<spanclass="title">partition</span>）。</span><spanclass="line"></span> <spanclass="line"><spanclass="title">public</span><spanclass="title">void</span><spanclass="title">sendMessage</span>()<spanclass="title">throws</span><spanclass="title">InterruptedException</span></span>{</span><spanclass="line"><spanclass="keyword">for</span>(<spanclass="keyword">int</span>i=<spanclass="number">1</span>;i<=<spanclass="number">5</span>;i++){</span><spanclass="line">      ListmessageList=<spanclass="keyword">new</span>ArrayList<KeyedMessage<String,String>>();</span><spanclass="line">      <spanclass="keyword">for</span>(<spanclass="keyword">int</span>j=<spanclass="number">0</span>;j<<spanclass="number">4</span>;j++）{</span><spanclass="line">          messageList.add(<spanclass="keyword">new</span>KeyedMessage<String,String>(<spanclass="string">"topic2"</span>,j+<spanclass="string">""</span>,<spanclass="string">"The "</span>+i+<spanclass="string">" message for key "</span>+j));</span><spanclass="line">      }</span><spanclass="line">      producer.send(messageList);</span><spanclass="line">    }</span><spanclass="line">producer.close();</span><spanclass="line">}</span> 

 <span class="line"> <span class="comment">############################# Log Retention Policy #############################</span></span> <span class="line"><span class="comment"># The following configurations control the disposal of log segments. The policy can</span></span> <span class="line"><span class="comment"># be set to delete segments after a period of time, or after a given size has accumulated.</span></span> <span class="line"><span class="comment"># A segment will be deleted whenever *either* of these criteria are met. Deletion always happens</span></span> <span class="line"><span class="comment"># from the end of the log.</span></span> <span class="line"><span class="comment"># The minimum age of a log file to be eligible for deletion</span></span> <span class="line">log.retention.hours=<span class="number">168</span></span> <span class="line"><span class="comment"># A size-based retention policy for logs. Segments are pruned from the log as long as the remaining</span></span> <span class="line"><span class="comment"># segments don't drop below log.retention.bytes.</span></span> <span class="line"><span class="comment">#log.retention.bytes=1073741824</span></span> <span class="line"><span class="comment"># The maximum size of a log segment file. When this size is reached a new log segment will be created.</span></span> <span class="line">log.segment.bytes=<span class="number">1073741824</span></span> <span class="line"><span class="comment"># The interval at which log segments are checked to see if they can be deleted according</span></span> <span class="line"><span class="comment"># to the retention policies</span></span> <span class="line">log.retention.check.interval.ms=<span class="number">300000</span></span> <span class="line"><span class="comment"># By default the log cleaner is disabled and the log retention policy will default to </span></span> <span class="line"><span class="comment">#just delete segments after their retention expires.</span></span> <span class="line"><span class="comment"># If log.cleaner.enable=true is set the cleaner will be enabled and individual logs </span></span> <span class="line"><span class="comment">#can then be marked for log compaction.</span></span> <span class="line">log.cleaner.enable=<span class="literal">false</span></span>1234567891011121314151617181920212223242526<spanclass="line"><spanclass="comment">############################# Log Retention Policy #############################</span></span> <spanclass="line"><spanclass="comment"># The following configurations control the disposal of log segments. The policy can</span></span><spanclass="line"><spanclass="comment"># be set to delete segments after a period of time, or after a given size has accumulated.</span></span><spanclass="line"><spanclass="comment"># A segment will be deleted whenever *either* of these criteria are met. Deletion always happens</span></span><spanclass="line"><spanclass="comment"># from the end of the log.</span></span> <spanclass="line"><spanclass="comment"># The minimum age of a log file to be eligible for deletion</span></span><spanclass="line">log.retention.hours=<spanclass="number">168</span></span> <spanclass="line"><spanclass="comment"># A size-based retention policy for logs. Segments are pruned from the log as long as the remaining</span></span><spanclass="line"><spanclass="comment"># segments don't drop below log.retention.bytes.</span></span><spanclass="line"><spanclass="comment">#log.retention.bytes=1073741824</span></span> <spanclass="line"><spanclass="comment"># The maximum size of a log segment file. When this size is reached a new log segment will be created.</span></span><spanclass="line">log.segment.bytes=<spanclass="number">1073741824</span></span> <spanclass="line"><spanclass="comment"># The interval at which log segments are checked to see if they can be deleted according</span></span><spanclass="line"><spanclass="comment"># to the retention policies</span></span><spanclass="line">log.retention.check.interval.ms=<spanclass="number">300000</span></span> <spanclass="line"><spanclass="comment"># By default the log cleaner is disabled and the log retention policy will default to </span></span><spanclass="line"><spanclass="comment">#just delete segments after their retention expires.</span></span><spanclass="line"><spanclass="comment"># If log.cleaner.enable=true is set the cleaner will be enabled and individual logs </span></span><spanclass="line"><spanclass="comment">#can then be marked for log compaction.</span></span><spanclass="line">log.cleaner.enable=<spanclass="literal">false</span></span> 

这里要注意，因为Kafka读取特定消息的时间复杂度为O(1)，即与文件大小无关，所以这里删除文件与Kafka性能无关，选择怎样的删除策略只与磁盘以及具体的需求有关。另外，Kafka会为每一个consumer group保留一些metadata信息–当前消费的消息的position，也即offset。这个offset由consumer控制。正常情况下consumer会在消费完一条消息后线性增加这个offset。当然，consumer也可将offset设成一个较小的值，重新消费一些消息。因为offet由consumer控制，所以Kafka broker是无状态的，它不需要标记哪些消息被哪些consumer过，不需要通过broker去保证同一个consumer group只有一个consumer能消费某一条消息，因此也就不需要锁机制，这也为Kafka的高吞吐率提供了有力保障。

Replication & Leader election

Kafka从0.8开始提供partition级别的replication，replication的数量可在 $KAFKA_HOME/config/server.properties 中配置。

 <span class="line">default.replication.factor = <span class="number">1</span></span>1<spanclass="line">default.replication.factor=<spanclass="number">1</span></span> 

 <span class="line"><span class="comment">#If a replica falls more than this many messages behind the leader, the leader will remove the follower from ISR and treat it as dead</span></span> <span class="line">replica.lag.max.messages=<span class="number">4000</span></span> <span class="line"><span class="comment">#If a follower hasn't sent any fetch requests for this window of time, the leader will remove the follower from ISR (in-sync replicas) and treat it as dead</span></span> <span class="line">replica.lag.time.max.ms=<span class="number">10000</span></span>12345<spanclass="line"><spanclass="comment">#If a replica falls more than this many messages behind the leader, the leader will remove the follower from ISR and treat it as dead</span></span><spanclass="line">replica.lag.max.messages=<spanclass="number">4000</span></span> <spanclass="line"><spanclass="comment">#If a follower hasn't sent any fetch requests for this window of time, the leader will remove the follower from ISR (in-sync replicas) and treat it as dead</span></span><spanclass="line">replica.lag.time.max.ms=<spanclass="number">10000</span></span> 

上文提到，在ISR中至少有一个follower时，Kafka可以确保已经commit的数据不丢失，但如果某一个partition的所有replica都挂了，就无法保证数据不丢失了。这种情况下有两种可行的方案：

• 等待ISR中的任一个replica“活”过来，并且选它作为leader
• 选择第一个“活”过来的replica（不一定是ISR中的）作为leader

这就需要在可用性和一致性当中作出一个简单的平衡。如果一定要等待ISR中的replica“活”过来，那不可用的时间就可能会相对较长。而且如果ISR中的所有replica都无法“活”过来了，或者数据都丢失了，这个partition将永远不可用。选择第一个“活”过来的replica作为leader，而这个replica不是ISR中的replica，那即使它并不保证已经包含了所有已commit的消息，它也会成为leader而作为consumer的数据源（前文有说明，所有读写都由leader完成）。Kafka0.8.*使用了第二种方式。根据Kafka的文档，在以后的版本中，Kafka支持用户通过配置选择这两种方式中的一种，从而根据不同的使用场景选择高可用性还是强一致性。

上文说明了一个parition的replication过程，然尔Kafka集群需要管理成百上千个partition，Kafka通过round-robin的方式来平衡partition从而避免大量partition集中在了少数几个节点上。同时Kafka也需要平衡leader的分布，尽可能的让所有partition的leader均匀分布在不同broker上。另一方面，优化leadership election的过程也是很重要的，毕竟这段时间相应的partition处于不可用状态。一种简单的实现是暂停宕机的broker上的所有partition，并为之选举leader。实际上，Kafka选举一个broker作为controller，这个controller通过watch Zookeeper检测所有的broker failure，并负责为所有受影响的parition选举leader，再将相应的leader调整命令发送至受影响的broker，过程如下图所示。

这样做的好处是，可以批量的通知leadership的变化，从而使得选举过程成本更低，尤其对大量的partition而言。如果controller失败了，幸存的所有broker都会尝试在Zookeeper中创建/controller->{this broker id}，如果创建成功（只可能有一个创建成功），则该broker会成为controller，若创建不成功，则该broker会等待新controller的命令。

Consumer group

（本节所有描述都是基于consumer hight level API而非low level API）。

每一个consumer实例都属于一个consumer group，每一条消息只会被同一个consumer group里的一个consumer实例消费。（不同consumer group可以同时消费同一条消息）

很多传统的message queue都会在消息被消费完后将消息删除，一方面避免重复消费，另一方面可以保证queue的长度比较少，提高效率。而如上文所将，Kafka并不删除已消费的消息，为了实现传统message queue消息只被消费一次的语义，Kafka保证保证同一个consumer group里只有一个consumer会消费一条消息。与传统message queue不同的是，Kafka还允许不同consumer group同时消费同一条消息，这一特性可以为消息的多元化处理提供了支持。实际上，Kafka的设计理念之一就是同时提供离线处理和实时处理。根据这一特性，可以使用Storm这种实时流处理系统对消息进行实时在线处理，同时使用Hadoop这种批处理系统进行离线处理，还可以同时将数据实时备份到另一个数据中心，只需要保证这三个操作所使用的consumer在不同的consumer group即可。下图展示了Kafka在Linkedin的一种简化部署。

为了更清晰展示Kafka consumer group的特性，笔者作了一项测试。创建一个topic (名为topic1)，创建一个属于group1的consumer实例，并创建三个属于group2的consumer实例，然后通过producer向topic1发送key分别为1，2，3r的消息。结果发现属于group1的consumer收到了所有的这三条消息，同时group2中的3个consumer分别收到了key为1，2，3的消息。如下图所示。

Consumer Rebalance

（本节所讲述内容均基于Kafka consumer high level API）

Kafka保证同一consumer group中只有一个consumer会消费某条消息，实际上，Kafka保证的是稳定状态下每一个consumer实例只会消费某一个或多个特定partition的数据，而某个partition的数据只会被某一个特定的consumer实例所消费。这样设计的劣势是无法让同一个consumer group里的consumer均匀消费数据，优势是每个consumer不用都跟大量的broker通信，减少通信开销，同时也降低了分配难度，实现也更简单。另外，因为同一个partition里的数据是有序的，这种设计可以保证每个partition里的数据也是有序被消费。

如果某consumer group中consumer数量少于partition数量，则至少有一个consumer会消费多个partition的数据，如果consumer的数量与partition数量相同，则正好一个consumer消费一个partition的数据，而如果consumer的数量多于partition的数量时，会有部分consumer无法消费该topic下任何一条消息。

如下例所示，如果topic1有0，1，2共三个partition，当group1只有一个consumer(名为consumer1)时，该 consumer可消费这3个partition的所有数据。

增加一个consumer(consumer2)后，其中一个consumer（consumer1）可消费2个partition的数据，另外一个consumer(consumer2)可消费另外一个partition的数据。

再增加一个consumer(consumer3)后，每个consumer可消费一个partition的数据。consumer1消费partition0，consumer2消费partition1，consumer3消费partition2

再增加一个consumer（consumer4）后，其中3个consumer可分别消费一个partition的数据，另外一个consumer（consumer4）不能消费topic1任何数据。

此时关闭consumer1，剩下的consumer可分别消费一个partition的数据。

接着关闭consumer2，剩下的consumer3可消费2个partition，consumer4可消费1个partition。

再关闭consumer3，剩下的consumer4可同时消费topic1的3个partition。

consumer rebalance算法如下：

• Sort PT (all partitions in topic T)
• Sort CG(all consumers in consumer group G)
• Let i be the index position of Ci in CG and let N=size(PT)/size(CG)
• Remove current entries owned by Ci from the partition owner registry
• Assign partitions from i N to (i+1) N-1 to consumer Ci
• Add newly assigned partitions to the partition owner registry

目前consumer rebalance的控制策略是由每一个consumer通过Zookeeper完成的。具体的控制方式如下：

• Register itself in the consumer id registry under its group.
• Register a watch on changes under the consumer id registry.
• Register a watch on changes under the broker id registry.
• If the consumer creates a message stream using a topic filter, it also registers a watch on changes under the broker topic registry.

• Force itself to rebalance within in its consumer group.

  在这种策略下，每一个consumer或者broker的增加或者减少都会触发consumer rebalance。因为每个consumer只负责调整自己所消费的partition，为了保证整个consumer group的一致性，所以当一个consumer触发了rebalance时，该consumer group内的其它所有consumer也应该同时触发rebalance。

目前（2015-01-19）最新版（0.8.2）Kafka采用的是上述方式。但该方式有不利的方面：

• Herd effect
  任何broker或者consumer的增减都会触发所有的consumer的rebalance
• Split Brain
  每个consumer分别单独通过Zookeeper判断哪些partition down了，那么不同consumer从Zookeeper“看”到的view就可能不一样，这就会造成错误的reblance尝试。而且有可能所有的consumer都认为rebalance已经完成了，但实际上可能并非如此。

根据Kafka官方文档，Kafka作者正在考虑在还未发布的 0.9.x版本中使用中心协调器(coordinator) 。大体思想是选举出一个broker作为coordinator，由它watch Zookeeper，从而判断是否有partition或者consumer的增减，然后生成rebalance命令，并检查是否这些rebalance在所有相关的consumer中被执行成功，如果不成功则重试，若成功则认为此次rebalance成功（这个过程跟replication controller非常类似，所以我很奇怪为什么当初设计replication controller时没有使用类似方式来解决consumer rebalance的问题）。流程如下：

消息Deliver guarantee

通过上文介绍，想必读者已经明天了producer和consumer是如何工作的，以及Kafka是如何做replication的，接下来要讨论的是Kafka如何确保消息在producer和consumer之间传输。有这么几种可能的delivery guarantee：

• At most once 消息可能会丢，但绝不会重复传输
• At least one 消息绝不会丢，但可能会重复传输
• Exactly once 每条消息肯定会被传输一次且仅传输一次，很多时候这是用户所想要的。

  Kafka的delivery guarantee semantic非常直接。当producer向broker发送消息时，一旦这条消息被commit，因数replication的存在，它就不会丢。但是如果producer发送数据给broker后，遇到的网络问题而造成通信中断，那producer就无法判断该条消息是否已经commit。这一点有点像向一个自动生成primary key的数据库表中插入数据。虽然Kafka无法确定网络故障期间发生了什么，但是producer可以生成一种类似于primary key的东西，发生故障时幂等性的retry多次，这样就做到了 Exactly one 。截止到目前(Kafka 0.8.2版本，2015-01-25)，这一feature还并未实现，有希望在Kafka未来的版本中实现。（所以目前默认情况下一条消息从producer和broker是确保了 At least once ，但可通过设置producer异步发送实现 At most once ）。

  接下来讨论的是消息从broker到consumer的delivery guarantee semantic。（仅针对Kafka consumer high level API）。consumer在从broker读取消息后，可以选择commit，该操作会在Zookeeper中存下该consumer在该partition下读取的消息的offset。该consumer下一次再读该partition时会从下一条开始读取。如未commit，下一次读取的开始位置会跟上一次commit之后的开始位置相同。当然可以将consumer设置为autocommit，即consumer一旦读到数据立即自动commit。如果只讨论这一读取消息的过程，那Kafka是确保了 Exactly once 。但实际上实际使用中consumer并非读取完数据就结束了，而是要进行进一步处理，而数据处理与commit的顺序在很大程度上决定了消息从broker和consumer的delivery guarantee semantic。

• 读完消息先commit再处理消息。这种模式下，如果consumer在commit后还没来得及处理消息就crash了，下次重新开始工作后就无法读到刚刚已提交而未处理的消息，这就对应于 At most once
• 读完消息先处理再commit。这种模式下，如果处理完了消息在commit之前consumer crash了，下次重新开始工作时还会处理刚刚未commit的消息，实际上该消息已经被处理过了。这就对应于 At least once 。在很多情况使用场景下，消息都有一个primary key，所以消息的处理往往具有幂等性，即多次处理这一条消息跟只处理一次是等效的，那就可以认为是 Exactly once 。（人个感觉这种说法有些牵强，毕竟它不是Kafka本身提供的机制，而且primary key本身不保证操作的幂等性。而且实际上我们说delivery guarantee semantic是讨论被处理多少次，而非处理结果怎样，因为处理方式多种多样，我们的系统不应该把处理过程的特性–如是否幂等性，当成Kafka本身的feature）
• 如果一定要做到 Exactly once ，就需要协调offset和实际操作的输出。精典的做法是引入两阶段提交。如果能让offset和操作输入存在同一个地方，会更简洁和通用。这种方式可能更好，因为许多输出系统可能不支持两阶段提交。比如，consumer拿到数据后可能把数据放到HDFS，如果把最新的offset和数据本身一起写到HDFS，那就可以保证数据的输出和offset的更新要么都完成，要么都不完成，间接实现 Exactly once 。（目前就high level API而言，offset是存于Zookeeper中的，无法存于HDFS，而low level API的offset是由自己去维护的，可以将之存于HDFS中）
  总之，Kafka默认保证 At least once ，并且允许通过设置producer异步提交来实现 At most once 。而 Exactly once 要求与目标存储系统协作，幸运的是Kafka提供的offset可以使用这种方式非常直接非常容易。

Benchmark

纸上得来终觉浅，绝知些事要躬行。笔者希望能亲自测一下Kafka的性能，而非从网上找一些测试数据。所以笔者曾在0.8发布前两个月做过详细的Kafka0.8性能测试，不过很可惜测试报告不慎丢失。所幸在网上找到了Kafka的创始人之一的 Jay Kreps的bechmark 。以下描述皆基于该benchmark。（该benchmark基于Kafka0.8.1）

测试环境

该benchmark用到了六台机器，机器配置如下

• Intel Xeon 2.5 GHz processor with six cores
• Six 7200 RPM SATA drives
• 32GB of RAM

• 1Gb Ethernet

  这6台机器其中3台用来搭建Kafka broker集群，另外3台用来安装Zookeeper及生成测试数据。6个drive都直接以非RAID方式挂载。实际上kafka对机器的需求与Hadoop的类似。

Producer吞吐率

该项测试只测producer的吞吐率，也就是数据只被持久化，没有consumer读数据。

1个producer线程，无replication

• Kafka确保写磁盘的过程是线性磁盘I/O，测试中使用的6块廉价磁盘线性I/O的最大吞吐量是822MB/second，这已经远大于1Gb网卡所能带来的吞吐量了。许多消息系统把数据持久化到磁盘当成是一个开销很大的事情，这是因为他们对磁盘的操作都不是线性I/O。
• 在每一个阶段，Kafka都尽量使用批量处理。如果想了解批处理在I/O操作中的重要性，可以参考David Patterson的” Latency Lags Bandwidth “

1个producer线程，3个异步replication

1个producer线程，3个同步replication

3个producer,3个异步replication

该测试相当于把上文中的1个producer,复制到了3台不同的机器上（在1台机器上跑多个实例对吞吐率的增加不会有太大帮忙，因为网卡已经基本饱和了），这3个producer同时发送数据。整个集群的吞吐率为 2,024,032 records/second （ 193,0MB/second ）。

Producer Throughput Vs. Stored Data

consumer吞吐率

需要注意的是，replication factor并不会影响consumer的吞吐率测试，因为consumer只会从每个partition的leader读数据，而与replicaiton factor无关。同样，consumer吞吐率也与同步复制还是异步复制无关。

1个consumer

3个consumer

Producer and Consumer

消息长度对吞吐率的影响

端到端的Latency

重现该benchmark

 <span class="line">Producer</span> <span class="line">Setup</span> <span class="line">bin/kafka-topics.sh --zookeeper esv4-hcl197.grid.linkedin.com:<span class="number">2181</span> --create --topic <span class="built_in">test</span>-rep-one --partitions <span class="number">6</span> --replication-factor <span class="number">1</span></span> <span class="line">bin/kafka-topics.sh --zookeeper esv4-hcl197.grid.linkedin.com:<span class="number">2181</span> --create --topic <span class="built_in">test</span> --partitions <span class="number">6</span> --replication-factor <span class="number">3</span></span> <span class="line">Single thread, no replication</span> <span class="line">bin/kafka-run-class.sh org.apache.kafka.clients.tools.ProducerPerformance <span class="built_in">test</span>7 <span class="number">50000000</span> <span class="number">100</span> -<span class="number">1</span> acks=<span class="number">1</span> bootstrap.servers=esv4-hcl198.grid.linkedin.com:<span class="number">9092</span> buffer.memory=<span class="number">67108864</span> batch.size=<span class="number">8196</span></span> <span class="line">Single-thread, async <span class="number">3</span>x replication</span> <span class="line">bin/kafktopics.sh --zookeeper esv4-hcl197.grid.linkedin.com:<span class="number">2181</span> --create --topic <span class="built_in">test</span> --partitions <span class="number">6</span> --replication-factor <span class="number">3</span></span> <span class="line">bin/kafka-run-class.sh org.apache.kafka.clients.tools.ProducerPerformance <span class="built_in">test</span>6 <span class="number">50000000</span> <span class="number">100</span> -<span class="number">1</span> acks=<span class="number">1</span> bootstrap.servers=esv4-hcl198.grid.linkedin.com:<span class="number">9092</span> buffer.memory=<span class="number">67108864</span> batch.size=<span class="number">8196</span></span> <span class="line">Single-thread, sync <span class="number">3</span>x replication</span> <span class="line">bin/kafka-run-class.sh org.apache.kafka.clients.tools.ProducerPerformance <span class="built_in">test</span> <span class="number">50000000</span> <span class="number">100</span> -<span class="number">1</span> acks=-<span class="number">1</span> bootstrap.servers=esv4-hcl198.grid.linkedin.com:<span class="number">9092</span> buffer.memory=<span class="number">67108864</span> batch.size=<span class="number">64000</span></span> <span class="line">Three Producers, <span class="number">3</span>x async replication</span> <span class="line">bin/kafka-run-class.sh org.apache.kafka.clients.tools.ProducerPerformance <span class="built_in">test</span> <span class="number">50000000</span> <span class="number">100</span> -<span class="number">1</span> acks=<span class="number">1</span> bootstrap.servers=esv4-hcl198.grid.linkedin.com:<span class="number">9092</span> buffer.memory=<span class="number">67108864</span> batch.size=<span class="number">8196</span></span> <span class="line">Throughput Versus Stored Data</span> <span class="line">bin/kafka-run-class.sh org.apache.kafka.clients.tools.ProducerPerformance <span class="built_in">test</span> <span class="number">50000000000</span> <span class="number">100</span> -<span class="number">1</span> acks=<span class="number">1</span> bootstrap.servers=esv4-hcl198.grid.linkedin.com:<span class="number">9092</span> buffer.memory=<span class="number">67108864</span> batch.size=<span class="number">8196</span></span> <span class="line">Effect of message size</span> <span class="line"><span class="keyword">for</span> i <span class="keyword">in</span> <span class="number">10</span> <span class="number">100</span> <span class="number">1000</span> <span class="number">10000</span> <span class="number">100000</span>;</span> <span class="line"><span class="keyword">do</span></span> <span class="line"><span class="built_in">echo</span> <span class="string">""</span></span> <span class="line"><span class="built_in">echo</span> <span class="variable">$i</span></span> <span class="line">bin/kafka-run-class.sh org.apache.kafka.clients.tools.ProducerPerformance <span class="built_in">test</span> $((<span class="number">1000</span>*<span class="number">1024</span>*<span class="number">1024</span>/<span class="variable">$i</span>)) <span class="variable">$i</span> -<span class="number">1</span> acks=<span class="number">1</span> bootstrap.servers=esv4-hcl198.grid.linkedin.com:<span class="number">9092</span> buffer.memory=<span class="number">67108864</span> batch.size=<span class="number">128000</span></span> <span class="line"><span class="keyword">done</span>;</span> <span class="line">Consumer</span> <span class="line">Consumer throughput</span> <span class="line">bin/kafka-consumer-perf-test.sh --zookeeper esv4-hcl197.grid.linkedin.com:<span class="number">2181</span> --messages <span class="number">50000000</span> --topic <span class="built_in">test</span> --threads <span class="number">1</span></span> <span class="line"><span class="number">3</span> Consumers</span> <span class="line">On three servers, run:</span> <span class="line">bin/kafka-consumer-perf-test.sh --zookeeper esv4-hcl197.grid.linkedin.com:<span class="number">2181</span> --messages <span class="number">50000000</span> --topic <span class="built_in">test</span> --threads <span class="number">1</span></span> <span class="line">End-to-end Latency</span> <span class="line">bin/kafka-run-class.sh kafka.tools.TestEndToEndLatency esv4-hcl198.grid.linkedin.com:<span class="number">9092</span> esv4-hcl197.grid.linkedin.com:<span class="number">2181</span> <span class="built_in">test</span> <span class="number">5000</span></span> <span class="line">Producer and consumer</span> <span class="line">bin/kafka-run-class.sh org.apache.kafka.clients.tools.ProducerPerformance <span class="built_in">test</span> <span class="number">50000000</span> <span class="number">100</span> -<span class="number">1</span> acks=<span class="number">1</span> bootstrap.servers=esv4-hcl198.grid.linkedin.com:<span class="number">9092</span> buffer.memory=<span class="number">67108864</span> batch.size=<span class="number">8196</span></span> <span class="line">bin/kafka-consumer-perf-test.sh --zookeeper esv4-hcl197.grid.linkedin.com:<span class="number">2181</span> --messages <span class="number">50000000</span> --topic <span class="built_in">test</span> --threads <span class="number">1</span></span>1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253<spanclass="line">Producer</span><spanclass="line">Setup</span><spanclass="line">bin/kafka-topics.sh--zookeeperesv4-hcl197.grid.linkedin.com:<spanclass="number">2181</span>--create--topic<spanclass="built_in">test</span>-rep-one--partitions<spanclass="number">6</span>--replication-factor<spanclass="number">1</span></span><spanclass="line">bin/kafka-topics.sh--zookeeperesv4-hcl197.grid.linkedin.com:<spanclass="number">2181</span>--create--topic<spanclass="built_in">test</span>--partitions<spanclass="number">6</span>--replication-factor<spanclass="number">3</span></span> <spanclass="line">Singlethread,noreplication</span> <spanclass="line">bin/kafka-run-class.shorg.apache.kafka.clients.tools.ProducerPerformance<spanclass="built_in">test</span>7<spanclass="number">50000000</span><spanclass="number">100</span>-<spanclass="number">1</span>acks=<spanclass="number">1</span>bootstrap.servers=esv4-hcl198.grid.linkedin.com:<spanclass="number">9092</span>buffer.memory=<spanclass="number">67108864</span>batch.size=<spanclass="number">8196</span></span> <spanclass="line">Single-thread,async<spanclass="number">3</span>xreplication</span> <spanclass="line">bin/kafktopics.sh--zookeeperesv4-hcl197.grid.linkedin.com:<spanclass="number">2181</span>--create--topic<spanclass="built_in">test</span>--partitions<spanclass="number">6</span>--replication-factor<spanclass="number">3</span></span><spanclass="line">bin/kafka-run-class.shorg.apache.kafka.clients.tools.ProducerPerformance<spanclass="built_in">test</span>6<spanclass="number">50000000</span><spanclass="number">100</span>-<spanclass="number">1</span>acks=<spanclass="number">1</span>bootstrap.servers=esv4-hcl198.grid.linkedin.com:<spanclass="number">9092</span>buffer.memory=<spanclass="number">67108864</span>batch.size=<spanclass="number">8196</span></span> <spanclass="line">Single-thread,sync<spanclass="number">3</span>xreplication</span> <spanclass="line">bin/kafka-run-class.shorg.apache.kafka.clients.tools.ProducerPerformance<spanclass="built_in">test</span><spanclass="number">50000000</span><spanclass="number">100</span>-<spanclass="number">1</span>acks=-<spanclass="number">1</span>bootstrap.servers=esv4-hcl198.grid.linkedin.com:<spanclass="number">9092</span>buffer.memory=<spanclass="number">67108864</span>batch.size=<spanclass="number">64000</span></span> <spanclass="line">ThreeProducers,<spanclass="number">3</span>xasyncreplication</span><spanclass="line">bin/kafka-run-class.shorg.apache.kafka.clients.tools.ProducerPerformance<spanclass="built_in">test</span><spanclass="number">50000000</span><spanclass="number">100</span>-<spanclass="number">1</span>acks=<spanclass="number">1</span>bootstrap.servers=esv4-hcl198.grid.linkedin.com:<spanclass="number">9092</span>buffer.memory=<spanclass="number">67108864</span>batch.size=<spanclass="number">8196</span></span> <spanclass="line">ThroughputVersusStoredData</span> <spanclass="line">bin/kafka-run-class.shorg.apache.kafka.clients.tools.ProducerPerformance<spanclass="built_in">test</span><spanclass="number">50000000000</span><spanclass="number">100</span>-<spanclass="number">1</span>acks=<spanclass="number">1</span>bootstrap.servers=esv4-hcl198.grid.linkedin.com:<spanclass="number">9092</span>buffer.memory=<spanclass="number">67108864</span>batch.size=<spanclass="number">8196</span></span> <spanclass="line">Effectofmessagesize</span> <spanclass="line"><spanclass="keyword">for</span>i<spanclass="keyword">in</span><spanclass="number">10</span><spanclass="number">100</span><spanclass="number">1000</span><spanclass="number">10000</span><spanclass="number">100000</span>;</span><spanclass="line"><spanclass="keyword">do</span></span><spanclass="line"><spanclass="built_in">echo</span><spanclass="string">""</span></span><spanclass="line"><spanclass="built_in">echo</span><spanclass="variable">$i</span></span><spanclass="line">bin/kafka-run-class.shorg.apache.kafka.clients.tools.ProducerPerformance<spanclass="built_in">test</span>$((<spanclass="number">1000</span>*<spanclass="number">1024</span>*<spanclass="number">1024</span>/<spanclass="variable">$i</span>))<spanclass="variable">$i</span>-<spanclass="number">1</span>acks=<spanclass="number">1</span>bootstrap.servers=esv4-hcl198.grid.linkedin.com:<spanclass="number">9092</span>buffer.memory=<spanclass="number">67108864</span>batch.size=<spanclass="number">128000</span></span><spanclass="line"><spanclass="keyword">done</span>;</span> <spanclass="line">Consumer</span><spanclass="line">Consumerthroughput</span> <spanclass="line">bin/kafka-consumer-perf-test.sh--zookeeperesv4-hcl197.grid.linkedin.com:<spanclass="number">2181</span>--messages<spanclass="number">50000000</span>--topic<spanclass="built_in">test</span>--threads<spanclass="number">1</span></span> <spanclass="line"><spanclass="number">3</span>Consumers</span> <spanclass="line">Onthreeservers,run:</span><spanclass="line">bin/kafka-consumer-perf-test.sh--zookeeperesv4-hcl197.grid.linkedin.com:<spanclass="number">2181</span>--messages<spanclass="number">50000000</span>--topic<spanclass="built_in">test</span>--threads<spanclass="number">1</span></span> <spanclass="line">End-to-endLatency</span> <spanclass="line">bin/kafka-run-class.shkafka.tools.TestEndToEndLatencyesv4-hcl198.grid.linkedin.com:<spanclass="number">9092</span>esv4-hcl197.grid.linkedin.com:<spanclass="number">2181</span><spanclass="built_in">test</span><spanclass="number">5000</span></span> <spanclass="line">Producerandconsumer</span> <spanclass="line">bin/kafka-run-class.shorg.apache.kafka.clients.tools.ProducerPerformance<spanclass="built_in">test</span><spanclass="number">50000000</span><spanclass="number">100</span>-<spanclass="number">1</span>acks=<spanclass="number">1</span>bootstrap.servers=esv4-hcl198.grid.linkedin.com:<spanclass="number">9092</span>buffer.memory=<spanclass="number">67108864</span>batch.size=<spanclass="number">8196</span></span> <spanclass="line">bin/kafka-consumer-perf-test.sh--zookeeperesv4-hcl197.grid.linkedin.com:<spanclass="number">2181</span>--messages<spanclass="number">50000000</span>--topic<spanclass="built_in">test</span>--threads<spanclass="number">1</span></span> 

broker配置如下

 <span class="line"><span class="comment">############################# Server Basics #############################</span></span> <span class="line"><span class="comment"># The id of the broker. This must be set to a unique integer for each broker.</span></span> <span class="line">broker.id=<span class="number">0</span></span> <span class="line"><span class="comment">############################# Socket Server Settings #############################</span></span> <span class="line"><span class="comment"># The port the socket server listens on</span></span> <span class="line">port=<span class="number">9092</span></span> <span class="line"><span class="comment"># Hostname the broker will bind to and advertise to producers and consumers.</span></span> <span class="line"><span class="comment"># If not set, the server will bind to all interfaces and advertise the value returned from</span></span> <span class="line"><span class="comment"># from java.net.InetAddress.getCanonicalHostName().</span></span> <span class="line"><span class="comment">#host.name=localhost</span></span> <span class="line"><span class="comment"># The number of threads handling network requests</span></span> <span class="line">num.network.threads=<span class="number">4</span></span> <span class="line"><span class="comment"># The number of threads doing disk I/O</span></span> <span class="line">num.io.threads=<span class="number">8</span></span> <span class="line"><span class="comment"># The send buffer (SO_SNDBUF) used by the socket server</span></span> <span class="line">socket.send.buffer.bytes=<span class="number">1048576</span></span> <span class="line"><span class="comment"># The receive buffer (SO_RCVBUF) used by the socket server</span></span> <span class="line">socket.receive.buffer.bytes=<span class="number">1048576</span></span> <span class="line"><span class="comment"># The maximum size of a request that the socket server will accept (protection against OOM)</span></span> <span class="line">socket.request.max.bytes=<span class="number">104857600</span></span> <span class="line"><span class="comment">############################# Log Basics #############################</span></span> <span class="line"><span class="comment"># The directory under which to store log files</span></span> <span class="line">log.dirs=/grid/a/dfs-data/kafka-logs,/grid/b/dfs-data/kafka-logs,/grid/c/dfs-data/kafka-logs,/grid/d/dfs-data/kafka-logs,/grid/e/dfs-data/kafka-logs,/grid/f/dfs-data/kafka-logs</span> <span class="line"><span class="comment"># The number of logical partitions per topic per server. More partitions allow greater parallelism</span></span> <span class="line"><span class="comment"># for consumption, but also mean more files.</span></span> <span class="line">num.partitions=<span class="number">8</span></span> <span class="line"><span class="comment">############################# Log Flush Policy #############################</span></span> <span class="line"><span class="comment"># The following configurations control the flush of data to disk. This is the most</span></span> <span class="line"><span class="comment"># important performance knob in kafka.</span></span> <span class="line"><span class="comment"># There are a few important trade-offs here:</span></span> <span class="line"><span class="comment"># 1. Durability: Unflushed data is at greater risk of loss in the event of a crash.</span></span> <span class="line"><span class="comment"># 2. Latency: Data is not made available to consumers until it is flushed (which adds latency).</span></span> <span class="line"><span class="comment"># 3. Throughput: The flush is generally the most expensive operation. </span></span> <span class="line"><span class="comment"># The settings below allow one to configure the flush policy to flush data after a period of time or</span></span> <span class="line"><span class="comment"># every N messages (or both). This can be done globally and overridden on a per-topic basis.</span></span> <span class="line"><span class="comment"># Per-topic overrides for log.flush.interval.ms</span></span> <span class="line"><span class="comment">#log.flush.intervals.ms.per.topic=topic1:1000, topic2:3000</span></span> <span class="line"><span class="comment">############################# Log Retention Policy #############################</span></span> <span class="line"><span class="comment"># The following configurations control the disposal of log segments. The policy can</span></span> <span class="line"><span class="comment"># be set to delete segments after a period of time, or after a given size has accumulated.</span></span> <span class="line"><span class="comment"># A segment will be deleted whenever *either* of these criteria are met. Deletion always happens</span></span> <span class="line"><span class="comment"># from the end of the log.</span></span> <span class="line"><span class="comment"># The minimum age of a log file to be eligible for deletion</span></span> <span class="line">log.retention.hours=<span class="number">168</span></span> <span class="line"><span class="comment"># A size-based retention policy for logs. Segments are pruned from the log as long as the remaining</span></span> <span class="line"><span class="comment"># segments don't drop below log.retention.bytes.</span></span> <span class="line"><span class="comment">#log.retention.bytes=1073741824</span></span> <span class="line"><span class="comment"># The maximum size of a log segment file. When this size is reached a new log segment will be created.</span></span> <span class="line">log.segment.bytes=<span class="number">536870912</span></span> <span class="line"><span class="comment"># The interval at which log segments are checked to see if they can be deleted according </span></span> <span class="line"><span class="comment"># to the retention policies</span></span> <span class="line">log.cleanup.interval.mins=<span class="number">1</span></span> <span class="line"><span class="comment">############################# Zookeeper #############################</span></span> <span class="line"><span class="comment"># Zookeeper connection string (see zookeeper docs for details).</span></span> <span class="line"><span class="comment"># This is a comma separated host:port pairs, each corresponding to a zk</span></span> <span class="line"><span class="comment"># server. e.g. "127.0.0.1:3000,127.0.0.1:3001,127.0.0.1:3002".</span></span> <span class="line"><span class="comment"># You can also append an optional chroot string to the urls to specify the</span></span> <span class="line"><span class="comment"># root directory for all kafka znodes.</span></span> <span class="line">zookeeper.connect=esv4-hcl197.grid.linkedin.com:<span class="number">2181</span></span> <span class="line"><span class="comment"># Timeout in ms for connecting to zookeeper</span></span> <span class="line">zookeeper.connection.timeout.ms=<span class="number">1000000</span></span> <span class="line"><span class="comment"># metrics reporter properties</span></span> <span class="line">kafka.metrics.polling.interval.secs=<span class="number">5</span></span> <span class="line">kafka.metrics.reporters=kafka.metrics.KafkaCSVMetricsReporter</span> <span class="line">kafka.csv.metrics.dir=/tmp/kafka_metrics</span> <span class="line"><span class="comment"># Disable csv reporting by default.</span></span> <span class="line">kafka.csv.metrics.reporter.enabled=<span class="literal">false</span></span> <span class="line">replica.lag.max.messages=<span class="number">10000000</span></span>1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192939495<spanclass="line"><spanclass="comment">############################# Server Basics #############################</span></span> <spanclass="line"><spanclass="comment"># The id of the broker. This must be set to a unique integer for each broker.</span></span><spanclass="line">broker.id=<spanclass="number">0</span></span> <spanclass="line"><spanclass="comment">############################# Socket Server Settings #############################</span></span> <spanclass="line"><spanclass="comment"># The port the socket server listens on</span></span><spanclass="line">port=<spanclass="number">9092</span></span> <spanclass="line"><spanclass="comment"># Hostname the broker will bind to and advertise to producers and consumers.</span></span><spanclass="line"><spanclass="comment"># If not set, the server will bind to all interfaces and advertise the value returned from</span></span><spanclass="line"><spanclass="comment"># from java.net.InetAddress.getCanonicalHostName().</span></span><spanclass="line"><spanclass="comment">#host.name=localhost</span></span> <spanclass="line"><spanclass="comment"># The number of threads handling network requests</span></span><spanclass="line">num.network.threads=<spanclass="number">4</span></span><spanclass="line"><spanclass="comment"># The number of threads doing disk I/O</span></span><spanclass="line">num.io.threads=<spanclass="number">8</span></span> <spanclass="line"><spanclass="comment"># The send buffer (SO_SNDBUF) used by the socket server</span></span><spanclass="line">socket.send.buffer.bytes=<spanclass="number">1048576</span></span> <spanclass="line"><spanclass="comment"># The receive buffer (SO_RCVBUF) used by the socket server</span></span><spanclass="line">socket.receive.buffer.bytes=<spanclass="number">1048576</span></span> <spanclass="line"><spanclass="comment"># The maximum size of a request that the socket server will accept (protection against OOM)</span></span><spanclass="line">socket.request.max.bytes=<spanclass="number">104857600</span></span>  <spanclass="line"><spanclass="comment">############################# Log Basics #############################</span></span> <spanclass="line"><spanclass="comment"># The directory under which to store log files</span></span><spanclass="line">log.dirs=/grid/a/dfs-data/kafka-logs,/grid/b/dfs-data/kafka-logs,/grid/c/dfs-data/kafka-logs,/grid/d/dfs-data/kafka-logs,/grid/e/dfs-data/kafka-logs,/grid/f/dfs-data/kafka-logs</span> <spanclass="line"><spanclass="comment"># The number of logical partitions per topic per server. More partitions allow greater parallelism</span></span><spanclass="line"><spanclass="comment"># for consumption, but also mean more files.</span></span><spanclass="line">num.partitions=<spanclass="number">8</span></span> <spanclass="line"><spanclass="comment">############################# Log Flush Policy #############################</span></span> <spanclass="line"><spanclass="comment"># The following configurations control the flush of data to disk. This is the most</span></span><spanclass="line"><spanclass="comment"># important performance knob in kafka.</span></span><spanclass="line"><spanclass="comment"># There are a few important trade-offs here:</span></span><spanclass="line"><spanclass="comment">#    1. Durability: Unflushed data is at greater risk of loss in the event of a crash.</span></span><spanclass="line"><spanclass="comment">#    2. Latency: Data is not made available to consumers until it is flushed (which adds latency).</span></span><spanclass="line"><spanclass="comment">#    3. Throughput: The flush is generally the most expensive operation. </span></span><spanclass="line"><spanclass="comment"># The settings below allow one to configure the flush policy to flush data after a period of time or</span></span><spanclass="line"><spanclass="comment"># every N messages (or both). This can be done globally and overridden on a per-topic basis.</span></span> <spanclass="line"><spanclass="comment"># Per-topic overrides for log.flush.interval.ms</span></span><spanclass="line"><spanclass="comment">#log.flush.intervals.ms.per.topic=topic1:1000, topic2:3000</span></span> <spanclass="line"><spanclass="comment">############################# Log Retention Policy #############################</span></span> <spanclass="line"><spanclass="comment"># The following configurations control the disposal of log segments. The policy can</span></span><spanclass="line"><spanclass="comment"># be set to delete segments after a period of time, or after a given size has accumulated.</span></span><spanclass="line"><spanclass="comment"># A segment will be deleted whenever *either* of these criteria are met. Deletion always happens</span></span><spanclass="line"><spanclass="comment"># from the end of the log.</span></span> <spanclass="line"><spanclass="comment"># The minimum age of a log file to be eligible for deletion</span></span><spanclass="line">log.retention.hours=<spanclass="number">168</span></span> <spanclass="line"><spanclass="comment"># A size-based retention policy for logs. Segments are pruned from the log as long as the remaining</span></span><spanclass="line"><spanclass="comment"># segments don't drop below log.retention.bytes.</span></span><spanclass="line"><spanclass="comment">#log.retention.bytes=1073741824</span></span> <spanclass="line"><spanclass="comment"># The maximum size of a log segment file. When this size is reached a new log segment will be created.</span></span><spanclass="line">log.segment.bytes=<spanclass="number">536870912</span></span> <spanclass="line"><spanclass="comment"># The interval at which log segments are checked to see if they can be deleted according </span></span><spanclass="line"><spanclass="comment"># to the retention policies</span></span><spanclass="line">log.cleanup.interval.mins=<spanclass="number">1</span></span> <spanclass="line"><spanclass="comment">############################# Zookeeper #############################</span></span> <spanclass="line"><spanclass="comment"># Zookeeper connection string (see zookeeper docs for details).</span></span><spanclass="line"><spanclass="comment"># This is a comma separated host:port pairs, each corresponding to a zk</span></span><spanclass="line"><spanclass="comment"># server. e.g. "127.0.0.1:3000,127.0.0.1:3001,127.0.0.1:3002".</span></span><spanclass="line"><spanclass="comment"># You can also append an optional chroot string to the urls to specify the</span></span><spanclass="line"><spanclass="comment"># root directory for all kafka znodes.</span></span><spanclass="line">zookeeper.connect=esv4-hcl197.grid.linkedin.com:<spanclass="number">2181</span></span> <spanclass="line"><spanclass="comment"># Timeout in ms for connecting to zookeeper</span></span><spanclass="line">zookeeper.connection.timeout.ms=<spanclass="number">1000000</span></span> <spanclass="line"><spanclass="comment"># metrics reporter properties</span></span><spanclass="line">kafka.metrics.polling.interval.secs=<spanclass="number">5</span></span><spanclass="line">kafka.metrics.reporters=kafka.metrics.KafkaCSVMetricsReporter</span><spanclass="line">kafka.csv.metrics.dir=/tmp/kafka_metrics</span><spanclass="line"><spanclass="comment"># Disable csv reporting by default.</span></span><spanclass="line">kafka.csv.metrics.reporter.enabled=<spanclass="literal">false</span></span> <spanclass="line">replica.lag.max.messages=<spanclass="number">10000000</span></span> 

读者也可参考另外一份 Kafka性能测试报告