iOS开发-学会使用代码块,升高你的开发作用

自家原创小说,头阵自本人村办博客站点,转发请务必注脚来源http://www.jasongj.com

澳门美高梅手机网站 1

个人博客上,本文链接http://www.jasongj.com/2015/01/02/Kafka%E6%B7%B1%E5%BA%A6%E8%A7%A3%E6%9E%90/

coldplay

察觉CSDN上有人转发本文,并标成他的原创小说,已向CSDN举报

深信广大开发者在初级阶段时都免不了记不住方法等丰盛多彩的泥坑,于是,很多时候,在遭受使用同样控件属性时,苦于记不住其项目不乏先例的代理方法,就不得不照着前面写过的代码再照搬五遍,又或者稍有经验的开发者在蒙受代码量略多但框架大体相同,唯有一线几处修改的急需时,copy从前写过的代码片段并举办适度的修改,成了在平时支出中“提升费用效能”的常用手法,可是频繁找寻从前的代码也是一件极为耗时的政工。

原稿地址—>MyBlog

唯独,好在苹果公司早已已经为开发者考虑到了那一点,在Xcode中为开发者准备好了“飞速方式”——代码块

代码块,很多刚接触iOS开发的新手可能并不知道那是怎么,甚至早已有2-3年干活经历的开发者没有使用过代码块的也大有人在。那么这几个代码块究竟是做怎么样的吗?

 

本人先来演示三次使用功能,相信我们便会一目了解。


近年来,我准备在viewController里使用一个tableView,须求用到其代理协议中的方法,于是:

澳门美高梅手机网站 2

背景介绍

有没有认为很神奇,这几个频率怎样呢,短短2分钟的时光(可能还不到),就写完了tableView代理协议中的多少个基本上必用到的措施,剩下只须求对没填写已毕的占位符举办填空就完事了,作用不可谓不快,那就是代码块在平常费用中的作用。


现在,大家对代码块的效劳应该早就精通了,那么下边,就让我们来看看哪些使用那么些代码块呢。

Kafka简介

  Kafka是一种分布式的,基于发布/订阅的音信系统。主要设计目的如下:

  • 以时间复杂度为O(1)的方法提供音讯持久化能力,即使对TB级以上数据也能担保常数时间的拜访品质
  • 高吞吐率。即便在那些廉价的商用机器上也能不辱义务单机扶助每秒100K条音信的传导
  • 支撑Kafka
    Server间的音信分区,及分布式消费,同时确保每个partition内的新闻顺序传输
  • 还要辅助离线数据处理和实时数据处理

代码块,顾名思义,就是一“块”嵌入的代码框架,提前将所需的代码框架写入代码块,仅留出可能爆发转移的地点用占位符代替,使用时,以自定义标记的按键呼出相应代码块,填写所需占位符即可已毕高功用的开支。

为啥要用新闻系统

  • 解耦
    在品种启动之初来预测将来项目会遇上什么要求,是极致忙绿的。音信队列在处理进程中间插入了一个包含的、基于数据的接口层,两边的处理进程都要促成这一接口。那允许你独自的扩充或涂改两边的处理进度,只要确保它们遵从同样的接口约束

  • 冗余
    稍微意况下,处理数量的进程会战败。除非数据被持久化,否则将导致丢失。信息队列把多少开展持久化直到它们已经被完全处理,通过这一艺术规避了数额丢失危害。在被许多音信队列所接纳的”插入-获取-删除”范式中,在把一个音讯从队列中去除以前,需求您的处理进程明确的提议该新闻已经被处理落成,确保您的多寡被乌海的保存直到你使用已毕。

  • 扩展性
    因为信息队列解耦了你的处理进程,所以增大音信入队和处理的功用是很简单的;只要此外增加处理进程即可。不要求改变代码、不必要调剂参数。扩张就好像调大电力按钮一样简单。

  • 世故 & 峰值处理能力
    在访问量剧增的情形下,应用仍旧须要三番五次发挥成效,可是这么的暴发流量并不常见;假诺为以能处理那类峰值访问为标准来投入资源随时待命无疑是宏大的荒废。使用音信队列可以使重点零部件顶住突发的走访压力,而不会因为突发的过分的请求而浑然崩溃。

  • 澳门美高梅手机网站,可苏醒性
    当系统的一有的零件失效,不会潜移默化到所有连串。信息队列下降了经过间的耦合度,所以纵然一个处理消息的进度挂掉,参与队列中的信息还是可以在系统复苏后被处理。而那种允许重试或者延后处理请求的能力一般是营造一个略感不便的用户和一个心灰意冷透顶的用户之间的分别。

  • 送达保险
    音信队列提供的冗余机制确保了音讯能被实际的拍卖,只要一个进度读取了该队列即可。在此基础上,IronMQ提供了一个”只送达一遍”有限支撑。无论有多少进度在从队列中领到数额,每一个消息只好被拍卖三遍。这所以成为可能,是因为获取一个新闻只是”预订”了那个音讯,暂时把它移出了队列。除非客户端明确的代表已经处理完了那一个音讯,否则那个音讯会被放回队列中去,在一段可配置的时刻未来可重复被拍卖。

  • 各类保险
    在大约选用景况下,数据处理的顺序都很重点。音讯队列本来就是排序的,并且能确保数据会根据一定的逐一来拍卖。IronMO有限帮忙新闻通过FIFO(先进先出)的种种来拍卖,因而音信在队列中的地方就是从队列中摸索他们的义务。

  • 缓冲
    在任何重大的连串中,都会有需要不一致的拍卖时间的因素。例如,加载一张图纸比使用过滤器开支更少的时刻。音信队列通过一个缓冲层来支持职分最高效能的执行—写入队列的处理会尽可能的疾速,而不受从队列读的预备处理的羁绊。该缓冲有助于控制和优化数据流经过系统的速度。

  • 驾驭数据流
    在一个分布式系统里,要取得一个关于用户操作会用多久及其原因的完整映像,是个伟大的挑衅。信息队列通过音信被拍卖的频率,来便宜的帮带确定那个表现不佳的处理进程或领域,这一个地方的数据流都不够优化。

  • 异步通讯
    无数时候,你不想也不须求立即处理音信。信息队列提供了异步处理体制,允许你把一个音讯放入队列,但并不登时处理它。你想向队列中放入多少音讯就放多少,然后在您愿意的时候再去处理它们。

1.先是,大家要现在类当上校大家所需的代码写好,以刚才自家所使用的tableView的代理方法为例:
#pragma mark -
#pragma mark - tableView
-(NSInteger)numberOfSectionsInTableView:(UITableView *)tableView
{
return 1;
}

-(NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section
{
return <#expression#>
}

-(UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
<#classCell#> * cell = [tableView dequeueReusableCellWithIdentifier:<#(nonnull NSString *)#>];

return cell;
}

-(void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath
{

}

-(CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath
{
return <#expression#>
}

**注:占位符的书写格式为<#name#>**

常用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仅提供非持久性的队列,也就是说若是宕机,数据将会丢掉。其中,推特(TWTR.US)的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是一个不行轻量级的音信系统,除了品质更加好之外,如故一个工作卓越的分布式系统。

2.写好代码之后,大家找到Xcode的右下角,如图的主意,找到代码块的存放处

澳门美高梅手机网站 3

Kafka解析

3.这几个便是我们存放代码块的地点,Xcode中提前已经准备了有的系统自带的不二法门

澳门美高梅手机网站 4

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可同时开支这一信息。
4.然后,我们需求做的就是将我们写好的代码 丢进 存放代码块的地方,你未曾看错,就是丢进去

澳门美高梅手机网站 5

Kafka架构

澳门美高梅手机网站 6
  如上图所示,一个独立的kafka集群中富含若干producer(可以是web前端爆发的page
view,或者是服务器日志,系统CPU、memory等),若干broker(Kafka扶助水平扩充,一般broker数量更多,集群吞吐率越高),若干consumer
group,以及一个Zookeeper集群。Kafka通过Zookeeper管理集群配置,选举leader,以及在consumer
group爆发变化时举行rebalance。producer使用push形式将音信表露到broker,consumer使用pull方式从broker订阅并用度音讯。
  

Title就是你那段代码在储存点要给显示出来的名字,图上标注的地方就是你呼出它所需键入的缩写,随便什么都足以,想些什么些什么,当然越短越好,那样,就水到渠成了下次要求运用的时候就只需打出你的缩写,那段代码就融洽调出去了

澳门美高梅手机网站 7

Push vs. Pull

  作为一个messaging
system,Kafka遵从了观念的法子,选拔由producer向broker
push信息并由consumer从broker pull新闻。一些logging-centric
system,比如非死不可的Scribe和Cloudera的Flume,选用卓殊区其余push格局。事实上,push形式和pull情势各有上下。
  push形式很难适应消费速率不相同的主顾,因为音信发送速率是由broker决定的。push形式的目的是拼命三郎以最连忙度传递音讯,不过如此很简单导致consumer来不及处理音信,典型的显现就是拒绝服务以及互联网不通。而pull格局则足以依照consumer的开支能力以适量的速率消费新闻。

6.尝试呼出您新建的代码块,就像最初阶我做的那么,即使代码块数量不多,也可以直接从储存点直接将其拖出来使用,像最初叶存放时做的均等,只但是我们是扭曲拖出来

Topic & Partition

  Topic在逻辑上可以被认为是一个queue。每条消费都不可以不指定它的topic,可以省略精晓为必须指明把那条新闻放进哪个queue里。为了使得Kafka的吞吐率可以水平扩大,物理上把topic分成一个或八个partition,每个partition在大体上相应一个文件夹,该文件夹下存储这些partition的保有音信和目录文件。
  澳门美高梅手机网站 8
  每个日志文件都是“log
entries”体系,每一个log entry含有一个4字节整型数(值为N),其后跟N个字节的信息体。每条音讯都有一个脚下partition下唯一的64字节的offset,它指明了那条新闻的原初地方。磁盘上囤积的音讯格式如下:
  message length : 4 bytes (value: 1+4+n)
  “magic” value : 1 byte
  crc : 4 bytes
  payload : n bytes
  这么些“log
entries”并非由一个文书构成,而是分成四个segment,每个segment名为该segment第一条音讯的offset和“.kafka”组成。其它会有一个目录文件,它注明了每个segment下富含的log entry的offset范围,如下图所示。
  澳门美高梅手机网站 9
  因为每条新闻都被append到该partition中,是各种写磁盘,由此效用格外高(经验证,顺序写磁盘作用比自由写内存还要高,那是Kafka高吞吐率的一个很关键的担保)。
  澳门美高梅手机网站 10
  每一条音信被发送到broker时,会基于paritition规则采纳被积存到哪一个partition。假诺partition规则设置的创制,所有消息可以均匀分布到分化的partition里,那样就落成了水平增加。(借使一个topic对应一个文件,这那几个文件所在的机器I/O将会变成那些topic的特性瓶颈,而partition解决了这些题材)。在创设topic时可以在$KAFKA_HOME/config/server.properties中指定那些partition的数量(如下所示),当然也足以在topic成立之后去修改parition数量。

# The default number of log partitions per topic. More partitions allow greater
# parallelism for consumption, but this will also result in more files across
# the brokers.
num.partitions=3

  在发送一条新闻时,可以指定那条新闻的key,producer依据这几个key和partition机制来判定将那条新闻发送到哪个parition。paritition机制能够经过点名producer的paritition.
class这一参数来指定,该class必须贯彻kafka.producer.Partitioner接口。本例中要是key可以被解析为整数则将相应的平头与partition总数取余,该音信会被发送到该数对应的partition。(每个parition都会有个序号)

import kafka.producer.Partitioner;
import kafka.utils.VerifiableProperties;

public class JasonPartitioner<T> implements Partitioner {

    public JasonPartitioner(VerifiableProperties verifiableProperties) {}

    @Override
    public int partition(Object key, int numPartitions) {
        try {
            int partitionNum = Integer.parseInt((String) key);
            return Math.abs(Integer.parseInt((String) key) % numPartitions);
        } catch (Exception e) {
            return Math.abs(key.hashCode() % numPartitions);
        }
    }
}

 
  倘若将上例中的class作为partition.class,并透过如下代码发送20条音讯(key分别为0,1,2,3)至topic2(包蕴4个partition)。
  

public void sendMessage() throws InterruptedException{
  for(int i = 1; i <= 5; i++){
        List messageList = new ArrayList<KeyedMessage<String, String>>();
        for(int j = 0; j < 4; j++){
            messageList.add(new KeyedMessage<String, String>("topic2", j+"", "The " + i + " message for key " + j));
        }
        producer.send(messageList);
    }
  producer.close();
}

  则key相同的音信会被发送并蕴藏到同一个partition里,而且key的序号正好和partition序号相同。(partition序号从0开头,本例中的key也恰恰从0开端)。如下图所示。
  澳门美高梅手机网站 11
  对于传统的message
queue而言,一般会删除已经被消费的新闻,而Kafka集群会保留所有的新闻,无论其被消费与否。当然,因为磁盘限制,不容许永远保存所有数据(实际上也没须求),由此Kafka提供三种政策去删除旧数据。一是基于时间,二是根据partition文件大小。例如可以通过陈设$KAFKA_HOME/config/server.properties,让Kafka删除一周前的数量,也可经过布署让Kafka在partition文件超过1GB时去除旧数据,如下所示。

  ############################# Log Retention Policy #############################

# The following configurations control the disposal of log segments. The policy can
# be set to delete segments after a period of time, or after a given size has accumulated.
# A segment will be deleted whenever *either* of these criteria are met. Deletion always happens
# from the end of the log.

# The minimum age of a log file to be eligible for deletion
log.retention.hours=168

# A size-based retention policy for logs. Segments are pruned from the log as long as the remaining
# segments don't drop below log.retention.bytes.
#log.retention.bytes=1073741824

# The maximum size of a log segment file. When this size is reached a new log segment will be created.
log.segment.bytes=1073741824

# The interval at which log segments are checked to see if they can be deleted according
# to the retention policies
log.retention.check.interval.ms=300000

# By default the log cleaner is disabled and the log retention policy will default to 
#just delete segments after their retention expires.
# If log.cleaner.enable=true is set the cleaner will be enabled and individual logs 
#can then be marked for log compaction.
log.cleaner.enable=false

  那里要小心,因为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的高吞吐率提供了强压保持。
     

7.要是需求对已经存好的代码块举办改动,那么只要求找到你的代码块,然后单机它,点击edit即可,要是想要删除代码块,只必要选中代码块,然后轻敲Backspace键,弹出选项框时选拔delete即可

谢谢您花时间阅读我的小说

Replication & Leader election

  Kafka从0.8始发提供partition级其他replication,replication的多少可在$KAFKA_HOME/config/server.properties中配置。

default.replication.factor = 1

  该 Replication与leader
election协作提供了活动的failover机制。replication对Kafka的吞吐率是有必然影响的,但庞大的拉长了可用性。默许意况下,Kafka的replication数量为1。  每个partition都有一个唯一的leader,所有的读写操作都在leader上成功,leader批量从leader上pull数据。一般情形下partition的数额超出等于broker的数额,并且具有partition的leader均匀分布在broker上。follower上的日志和其leader上的一点一滴等同。
  和半数以上分布式系统一样,Kakfa处理战败要求明确定义一个broker是不是alive。对于Kafka而言,Kafka存活包涵五个标准,一是它必须有限帮忙与Zookeeper的session(那个通过Zookeeper的heartbeat机制来落到实处)。二是follower必须能够登时将leader的writing复制过来,无法“落后太多”。
  leader会track“in sync”的node
list。如若一个follower宕机,或者落后太多,leader将把它从”in sync”
list中移除。那里所讲述的“落后太多”指follower复制的新闻落后于leader后的条数当先预约值,该值可在$KAFKA_HOME/config/server.properties中配置

#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
replica.lag.max.messages=4000

#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
replica.lag.time.max.ms=10000  

  须要表达的是,Kafka只解决”fail/recover”,不处理“Byzantine”(“拜占庭”)难点。
  一条音信只有被“in sync”
list里的所有follower都从leader复制过去才会被认为已交由。那样就防止了有些多少被写进了leader,还没赶趟被别的follower复制就宕机了,而致使数据丢失(consumer不可以消费那个多少)。而对此producer而言,它可以选用是或不是等待信息commit,那足以经过request.required.acks来安装。那种体制有限支撑了一旦“in
sync” list有一个或以上的flollower,一条被commit的消息就不会丢掉。
  那里的复制机制即不是一道复制,也不是独自的异步复制。事实上,同步复制须求“活着的”follower都复制完,那条新闻才会被认为commit,那种复制方式极大的影响了吞吐率(高吞吐率是Kafka卓殊关键的一个特点)。而异步复制格局下,follower异步的从leader复制数据,数据如若被leader写入log就被认为曾经commit,那种处境下如若follwer都掉队于leader,而leader突然宕机,则会丢掉数据。而Kafka的那种使用“in
sync”
list的主意则很好的户均了担保数据不丢掉以及吞吐率。follower可以批量的从leader复制数据,那样庞大的增长复制品质(批量写磁盘),极大裁减了follower与leader的不相同(前文有说到,只要follower落后leader不太远,则被认为在“in
sync” list里)。
  
  上文表明了Kafka是何等做replication的,其余一个很关键的标题是当leader宕机了,怎么样在follower中选出出新的leader。因为follower可能落后许多或者crash了,所以必须有限支撑选取“最新”的follower作为新的leader。一个着力的条件就是,如果leader不在了,新的leader必须持有原来的leader
commit的有着音信。那就需求作一个和平解决,假设leader在表Bellamy条新闻被commit前等待更加多的follower确认,那在它die之后就有愈来愈多的follower可以看作新的leader,但那也会招致吞吐率的低沉。
  一种更加常用的公推leader的情势是“majority
vote”(“少数遵从多数”),但Kafka并未选取那种艺术。那种方式下,若是我们有2f+1个replica(包罗leader和follower),那在commit此前必须确保有f+1个replica复制完音讯,为了有限支撑科学选出新的leader,fail的replica不可能领先f个。因为在剩余的任意f+1个replica里,至少有一个replica包蕴有最新的装有音讯。那种方法有个很大的优势,系统的latency只在于最快的几台server,也就是说,倘若replication
factor是3,那latency就取决于最快的更加follower而非最慢那么些。majority
vote也有一对逆风局,为了有限支持leader
election的常规开展,它所能容忍的fail的follower个数相比较少。若是要忍受1个follower挂掉,必要求有3个以上的replica,即使要忍耐2个follower挂掉,必要求有5个以上的replica。也就是说,在生养环境下为了确保较高的容错程度,必须求有大气的replica,而大气的replica又会在大数据量下导致品质的急剧下落。那就是那种算法越来越多用在Zookeeper那种共享集群配置的系列中而很少在须要仓储大批量数量的连串中选用的缘由。例如HDFS的HA
feature是基于majority-vote-based
journal
,然而它的数目存储并从未采取那种expensive的不二法门。
  实际上,leader
election算法至极多,比如Zookeper的ZabRaftViewstamped
Replication
。而Kafka所采用的leader
election算法更像微软的PacificA算法。
  Kafka在Zookeeper中动态维护了一个ISR(in-sync replicas)
set,这么些set里的保有replica都跟上了leader,唯有ISR里的积极分子才有被选为leader的或者。在那种方式下,对于f+1个replica,一个Kafka
topic能在担保不丢掉已经ommit的音讯的前提下容忍f个replica的破产。在大多数行使景况中,那种方式是不行有益的。事实上,为了容忍f个replica的败北,majority
vote和ISR在commit前要求等待的replica数量是千篇一律的,不过ISR须求的总的replica的个数大约是majority
vote的一半。
  尽管majority
vote与ISR相比较有不需等候最慢的server这一优势,可是Kafka作者认为Kafka可以透过producer接纳是还是不是被commit阻塞来革新这一标题,并且节省下来的replica和磁盘使得ISR情势照旧值得。
  
  上文提到,在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,进度如下图所示。
  澳门美高梅手机网站 12
  
  那样做的好处是,可以批量的通报leadership的变通,从而使得选举进程费用更低,尤其对大气的partition而言。即使controller战败了,幸存的装有broker都会尝试在Zookeeper中创设/controller->{this
broker
id},如若创制成功(只可能有一个创制成功),则该broker会成为controller,若创立不成事,则该broker会等待新controller的命令。
  澳门美高梅手机网站 13

代码块你会用了呢?

Consumer group

  (本节具备描述都是基于consumer hight level API而非low level
API)。
  每一个consumer实例都属于一个consumer
group,每一条音讯只会被同一个consumer
group里的一个consumer实例消费。(差距consumer
group可以同时开销一样条音信)
  澳门美高梅手机网站 14
  
  很多观念的message
queue都会在音信被消费完后将信息删除,一方面避免重复消费,另一方面能够有限支撑queue的长度比较少,提升功用。而如上文所将,Kafka并不删除已费用的新闻,为了贯彻传统message
queue信息只被消费一次的语义,Kafka保险保障同一个consumer
group里只有一个consumer会消费一条音讯。与观念message
queue不一致的是,Kafka还允许分裂consumer
group同时费用一样条音讯,这一特色可以为新闻的多元化处理提供了辅助。实际上,Kafka的安顿性理念之一就是还要提供离线处理和实时处理。根据这一特征,可以行使Storm那种实时流处理系统对信息举办实时在线处理,同时选用Hadoop那种批处理系统开展离线处理,还足以同时将数据实时备份到另一个多少主题,只要求确保这两个操作所采用的consumer在分裂的consumer
group即可。下图突显了Kafka在Linkedin的一种简化安顿。
  澳门美高梅手机网站 15
  为了更清晰体现Kafka consumer
group的特性,作者作了一项测试。创制一个topic
(名为topic1),创设一个属于group1的consumer实例,并创办多少个属于group2的consumer实例,然后经过producer向topic1发送key分别为1,2,3r的音讯。结果发现属于group1的consumer收到了拥有的那三条信息,同时group2中的3个consumer分别接受了key为1,2,3的音信。如下图所示。
  澳门美高梅手机网站 16

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的具备数据。
  澳门美高梅手机网站 17
  伸张一个consumer(consumer2)后,其中一个consumer(consumer1)可消费2个partition的数目,其它一个consumer(consumer2)可消费此外一个partition的数码。
  澳门美高梅手机网站 18
  再增添一个consumer(consumer3)后,每个consumer可消费一个partition的数量。consumer1消费partition0,consumer2消费partition1,consumer3消费partition2
  澳门美高梅手机网站 19
  再增加一个consumer(consumer4)后,其中3个consumer可分别消费一个partition的数据,其它一个consumer(consumer4)不可能消费topic1其余数据。
  澳门美高梅手机网站 20
  此时闭馆consumer1,剩下的consumer可分别消费一个partition的数额。
  澳门美高梅手机网站 21
  接着关闭consumer2,剩下的consumer3可消费2个partition,consumer4可消费1个partition。
  澳门美高梅手机网站 22
  再关闭consumer3,剩下的consumer4可同时开销topic1的3个partition。
  澳门美高梅手机网站 23

  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 iN 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的题材)。流程如下:
  澳门美高梅手机网站 24     

消息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

  在这一测试中,创造了一个分包6个partition且从未replication的topic。然后通过一个线程尽可能快的浮动50
million条相比短(payload100字节长)的新闻。测试结果是821,557
records/second(78.3MB/second)。
  之所以拔取短信息,是因为对于信息系统来说那种应用境况更难。因为一旦利用MB/second来表征吞吐率,那发送长新闻属实能使得测试结果更好。
  整个测试中,都是用每分钟delivery的音信的多寡乘以payload的长度来计量MB/second的,没有把新闻的元信息算在内,所以实际上的网络使用量会比这些大。对于本测试来说,每趟还需传输额外的22个字节,包蕴一个可选的key,信息长度描述,CRC等。其它,还蕴藏部分请求相关的overhead,比如topic,partition,acknowledgement等。那就招致大家比较难判定是不是已经达到网卡极限,不过把那一个overhead都算在吞吐率里面应该更客观一些。由此,我们早已主导达成了网卡的巅峰。
  开始观察此结果会认为它比人们所预期的要高很多,特别当考虑到Kafka要把数据持久化到磁盘当中。实际上,借使接纳随机走访数据系统,比如RDBMS,或者key-velue
store,可预料的参天访问频率大概是5000到50000个请求每秒,那和一个好的RPC层所能接受的远程请求量几乎。而该测试中远超于此的因由有三个。

  • Kafka确保写磁盘的经过是线性磁盘I/O,测试中运用的6块廉价磁盘线性I/O的最大吞吐量是822MB/second,这一度远大于1Gb网卡所能带来的吞吐量了。许多信息系统把多少持久化到磁盘当成是一个花费很大的政工,那是因为他们对磁盘的操作都不是线性I/O。
  • 在每一个阶段,Kafka都尽心尽力利用批量处理。假如想明白批处理在I/O操作中的紧要性,可以参照大卫Patterson的”Latency Lags
    Bandwidth

1个producer线程,3个异步replication

  该项测试与上一测试主旨一样,唯一的分别是各类partition有3个replica(所以网络传输的和写入磁盘的总的数据量扩大了3倍)。每一个broker即要写作为leader的partition,也要读(从leader读数据)写(将数据写到磁盘)作为follower的partition。测试结果为786,980
records/second(75.1MB/second)。
  该项测试中replication是异步的,也就是说broker收到多少并写入当地磁盘后就acknowledge
producer,而无需等所有replica都落成replication。也就是说,假诺leader
crash了,可能会丢掉一些最新的还未备份的数目。但那也会让message
acknowledgement延迟更少,实时性更好。
  那项测试评释,replication可以很快。整个集群的写能力也许会由于3倍的replication而唯有原来的三分之一,可是对于每一个producer来说吞吐率依旧十足好。
  

1个producer线程,3个同步replication

  该项测试与上一测试的绝无仅有差别是replication是联合的,每条音信唯有在被in sync集合里的装有replica都复制过去后才会被置为committed(此时broker会向producer发送acknowledgement)。在那种方式下,Kafka可以确保即使leader
crash了,也不会有数据丢失。测试结果为421,823
records/second(40.2MB/second)。
  Kafka同步复制与异步复制并不曾精神的不比。leader会始终track follower
replica从而监控它们是否还alive,只有拥有in sync集合里的replica都acknowledge的新闻才可能被consumer所消费。而对follower的等候影响了吞吐率。可以因此增大batch
size来改正那种景色,但为了幸免特定的优化而影响测试结果的可比性,本次测试并不曾做那种调整。
  

3个producer,3个异步replication

  该测试相当于把上文中的1个producer,复制到了3台不一致的机器上(在1台机械上跑多少个实例对吞吐率的充实不会有太大扶持,因为网卡已经主导饱和了),那3个producer同时发送数据。整个集群的吞吐率为2,024,032
records/second(193,0MB/second)。

Producer Throughput Vs. Stored Data

  音信系统的一个隐秘的高危是当数码能都存于内存时品质很好,但当数据量太大无法完全存于内存中时(然后众多新闻系统都会去除已经被消费的多寡,但当消费速度比生产速度慢时,仍会造成数据的积聚),数据会被更换来磁盘,从而使得吞吐率下降,那又扭曲导致系统无法即时接收数据。那样就老大倒霉,而事实上很多气象下选用queue的目的就是解决数量消费速度和生育速度不雷同的题目。
  但Kafka不设有这一标题,因为Kafka始终以O(1)的时间复杂度将数据持久化到磁盘,所以其吞吐率不受磁盘上所蕴藏的数据量的影响。为了表明这一风味,做了一个长日子的大数据量的测试,下图是吞吐率与数据量大小的涉及图。
  澳门美高梅手机网站 25
  上图中有部分variance的存在,并可以显明看出,吞吐率并不受磁盘上所存数据量大小的熏陶。实际上从上图可以看到,当磁盘数据量达到1TB时,吞吐率和磁盘数据唯有几百MB风尚未明确有别于。
  那一个variance是由Linux
I/O管理造成的,它会把数量缓存起来再批量flush。上图的测试结果是在生产环境中对Kafka集群做了些tuning后拿走的,那一个tuning方法可参看这里
  

consumer吞吐率

  需求留意的是,replication
factor并不会影响consumer的吞吐率测试,因为consumer只会从每个partition的leader读数据,而与replicaiton
factor非亲非故。同样,consumer吞吐率也与一头复制依然异步复制非亲非故。   

1个consumer

  该测试从有6个partition,3个replication的topic消费50
million的音信。测试结果为940,521 records/second(89.7MB/second)。
  能够寓目,Kafkar的consumer是极度高效的。它直接从broker的文件系统里读取文件块。Kafka使用sendfile
API
来一向通过操作系统间接传输,而不用把多少拷贝到用户空间。该项测试实际上从log的开头处起先读数据,所以它做了真格的的I/O。在生育环境下,consumer能够一向读取producer刚刚写下的数额(它可能还在缓存中)。实际上,倘诺在生养环境下跑I/O
stat
,你可以见到基本上并未物理“读”。也就是说生产条件下consumer的吞吐率会比该项测试中的要高。

3个consumer

  将地方的consumer复制到3台不一样的机器上,并且相互运行它们(从同一个topic上消费数据)。测试结果为2,615,968
records/second(249.5MB/second)。
  正如所预期的那样,consumer的吞吐率几乎线性增涨。   

Producer and Consumer

  上面的测试只是把producer和consumer分开测试,而该项测试同时运行producer和consumer,这更接近使用处境。实际上近年来的replication系统中follower就相当于consumer在办事。
  该项测试,在具备6个partition和3个replica的topic上同时使用1个producer和1个consumer,并且应用异步复制。测试结果为795,064
records/second(75.8MB/second)。
  可以看出,该项测试结果与独立测试1个producer时的结果大概一样。所以说consumer格外轻量级。
  

音信长度对吞吐率的影响

  上边的保有测试都根据短信息(payload
100字节),而正如上文所说,短新闻对Kafka来说是更难处理的采纳方法,可以预想,随着消息长度的叠加,records/second会减小,但MB/second会有所进步。下图是records/second与消息长度的关系图。
  澳门美高梅手机网站 26
  正如我们所预期的那么,随着音信长度的增多,每分钟所能发送的音信的数目逐步滑坡。然而借使看每秒钟发(英文名:zhōng fā)送的信息的总大小,它会趁机音信长度的充实而充实,如下图所示。
  澳门美高梅手机网站 27
  从上图可以看到,当音讯长度为10字节时,因为要反复入队,花了太多时光得到锁,CPU成了瓶颈,并无法丰裕利用带宽。但从100字节开首,大家得以见见带宽的应用渐渐趋向饱和(尽管MB/second如故会随着音信长度的充实而充实,但净增的宽窄也进一步小)。
  

端到端的Latency

  上文中啄磨了吞吐率,那消息传输的latency如何呢?也就是说音信从producer到consumer须要有些时间吗?该项测试创建1个producer和1个consumer并再三计时。结果是,2
ms (median), 3ms (99th percentile, 14ms (99.9th percentile)。
  (那里并从未注脚topic有稍许个partition,也向来不证实有微微个replica,replication是联名如故异步。实际上那会大幅度影响producer发送的音信被commit的latency,而唯有committed的新闻才能被consumer所消费,所以它会最终影响端到端的latency)
  

重现该benchmark

  如果读者想要在温馨的机器上复发这次benchmark测试,可以参照此次测试的配置和所利用的通令
  实际上Kafka
Distribution提供了producer质量测试工具,可通过bin/kafka-producer-perf-test.sh脚本来启动。所利用的命令如下
  

Producer
Setup
bin/kafka-topics.sh --zookeeper esv4-hcl197.grid.linkedin.com:2181 --create --topic test-rep-one --partitions 6 --replication-factor 1
bin/kafka-topics.sh --zookeeper esv4-hcl197.grid.linkedin.com:2181 --create --topic test --partitions 6 --replication-factor 3

Single thread, no replication

bin/kafka-run-class.sh org.apache.kafka.clients.tools.ProducerPerformance test7 50000000 100 -1 acks=1 bootstrap.servers=esv4-hcl198.grid.linkedin.com:9092 buffer.memory=67108864 batch.size=8196

Single-thread, async 3x replication

bin/kafktopics.sh --zookeeper esv4-hcl197.grid.linkedin.com:2181 --create --topic test --partitions 6 --replication-factor 3
bin/kafka-run-class.sh org.apache.kafka.clients.tools.ProducerPerformance test6 50000000 100 -1 acks=1 bootstrap.servers=esv4-hcl198.grid.linkedin.com:9092 buffer.memory=67108864 batch.size=8196

Single-thread, sync 3x replication

bin/kafka-run-class.sh org.apache.kafka.clients.tools.ProducerPerformance test 50000000 100 -1 acks=-1 bootstrap.servers=esv4-hcl198.grid.linkedin.com:9092 buffer.memory=67108864 batch.size=64000

Three Producers, 3x async replication
bin/kafka-run-class.sh org.apache.kafka.clients.tools.ProducerPerformance test 50000000 100 -1 acks=1 bootstrap.servers=esv4-hcl198.grid.linkedin.com:9092 buffer.memory=67108864 batch.size=8196

Throughput Versus Stored Data

bin/kafka-run-class.sh org.apache.kafka.clients.tools.ProducerPerformance test 50000000000 100 -1 acks=1 bootstrap.servers=esv4-hcl198.grid.linkedin.com:9092 buffer.memory=67108864 batch.size=8196

Effect of message size

for i in 10 100 1000 10000 100000;
do
echo ""
echo $i
bin/kafka-run-class.sh org.apache.kafka.clients.tools.ProducerPerformance test $((1000*1024*1024/$i)) $i -1 acks=1 bootstrap.servers=esv4-hcl198.grid.linkedin.com:9092 buffer.memory=67108864 batch.size=128000
done;

Consumer
Consumer throughput

bin/kafka-consumer-perf-test.sh --zookeeper esv4-hcl197.grid.linkedin.com:2181 --messages 50000000 --topic test --threads 1

3 Consumers

On three servers, run:
bin/kafka-consumer-perf-test.sh --zookeeper esv4-hcl197.grid.linkedin.com:2181 --messages 50000000 --topic test --threads 1

End-to-end Latency

bin/kafka-run-class.sh kafka.tools.TestEndToEndLatency esv4-hcl198.grid.linkedin.com:9092 esv4-hcl197.grid.linkedin.com:2181 test 5000

Producer and consumer

bin/kafka-run-class.sh org.apache.kafka.clients.tools.ProducerPerformance test 50000000 100 -1 acks=1 bootstrap.servers=esv4-hcl198.grid.linkedin.com:9092 buffer.memory=67108864 batch.size=8196

bin/kafka-consumer-perf-test.sh --zookeeper esv4-hcl197.grid.linkedin.com:2181 --messages 50000000 --topic test --threads 1

  broker配置如下

############################# Server Basics #############################

# The id of the broker. This must be set to a unique integer for each broker.
broker.id=0

############################# Socket Server Settings #############################

# The port the socket server listens on
port=9092

# Hostname the broker will bind to and advertise to producers and consumers.
# If not set, the server will bind to all interfaces and advertise the value returned from
# from java.net.InetAddress.getCanonicalHostName().
#host.name=localhost

# The number of threads handling network requests
num.network.threads=4

# The number of threads doing disk I/O
num.io.threads=8

# The send buffer (SO_SNDBUF) used by the socket server
socket.send.buffer.bytes=1048576

# The receive buffer (SO_RCVBUF) used by the socket server
socket.receive.buffer.bytes=1048576

# The maximum size of a request that the socket server will accept (protection against OOM)
socket.request.max.bytes=104857600


############################# Log Basics #############################

# The directory under which to store log files
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

# The number of logical partitions per topic per server. More partitions allow greater parallelism
# for consumption, but also mean more files.
num.partitions=8

############################# Log Flush Policy #############################

# The following configurations control the flush of data to disk. This is the most
# important performance knob in kafka.
# There are a few important trade-offs here:
#    1. Durability: Unflushed data is at greater risk of loss in the event of a crash.
#    2. Latency: Data is not made available to consumers until it is flushed (which adds latency).
#    3. Throughput: The flush is generally the most expensive operation. 
# The settings below allow one to configure the flush policy to flush data after a period of time or
# every N messages (or both). This can be done globally and overridden on a per-topic basis.

# Per-topic overrides for log.flush.interval.ms
#log.flush.intervals.ms.per.topic=topic1:1000, topic2:3000

############################# Log Retention Policy #############################

# The following configurations control the disposal of log segments. The policy can
# be set to delete segments after a period of time, or after a given size has accumulated.
# A segment will be deleted whenever *either* of these criteria are met. Deletion always happens
# from the end of the log.

# The minimum age of a log file to be eligible for deletion
log.retention.hours=168

# A size-based retention policy for logs. Segments are pruned from the log as long as the remaining
# segments don't drop below log.retention.bytes.
#log.retention.bytes=1073741824

# The maximum size of a log segment file. When this size is reached a new log segment will be created.
log.segment.bytes=536870912

# The interval at which log segments are checked to see if they can be deleted according 
# to the retention policies
log.cleanup.interval.mins=1

############################# Zookeeper #############################

# Zookeeper connection string (see zookeeper docs for details).
# This is a comma separated host:port pairs, each corresponding to a zk
# server. e.g. "127.0.0.1:3000,127.0.0.1:3001,127.0.0.1:3002".
# You can also append an optional chroot string to the urls to specify the
# root directory for all kafka znodes.
zookeeper.connect=esv4-hcl197.grid.linkedin.com:2181

# Timeout in ms for connecting to zookeeper
zookeeper.connection.timeout.ms=1000000

# metrics reporter properties
kafka.metrics.polling.interval.secs=5
kafka.metrics.reporters=kafka.metrics.KafkaCSVMetricsReporter
kafka.csv.metrics.dir=/tmp/kafka_metrics
# Disable csv reporting by default.
kafka.csv.metrics.reporter.enabled=false

replica.lag.max.messages=10000000

  读者也可参考其余一份Kafka质量测试报告   

迎接关心群众号【大数目架构】

澳门美高梅手机网站 28

参考

 

发表评论

电子邮件地址不会被公开。 必填项已用*标注