国产aⅴ无码专区亚洲av麻豆,亚洲影院在线观看,久久久久亚洲AV成人网

kafka配置举例

陕西BOY — Wed, 08 Jan 2014 04:08:00 GMT

##broker标识,id为正�?且全局不得重复.

broker.id=0

##日志文�g保存的目�? 推荐攑ֈ�存储大的盘目�?/div>

log.dirs=/opt/kafkadata/logs

##broker需要��用zookeeper保存meata信息,因此broker为zk

##此处为zookeeper集群的connectString,后面可以跟上path

##不过需要注�?path的全路径需要有自己来创�?使用zookeeper脚本工具)

zookeeper.connect=hostname1:port1,hostname2:port2/kafka

##用来侦听链接的端�?prudcer或consumer��在此端口徏立链�?

port=10000

##指定broker实例�l�定的网�l�接口地址

host.name=ip

##每个topic默认partition的个�?默认�?

num.partitions=2

##日志文�g中每个segment文�g的尺�?默认�?G

##log.segment.bytes=1024*1024*1024

##滚动生成新的segment文�g的最大时�?

##log.roll.hours=24*7

##segment文�g保留的最长时�?��时��被删除

##log.retention.hours=24*7

##partiton中buffer�?消息的条�?辑ֈ�阀�?��触发flush到磁�?

log.flush.interval.messages=30000

#消息buffer的时�?辑ֈ�阀�?��触发flush到磁�?

log.flush.interval.ms=5000

##partition leader�{�待follower同步消息的最大时�?

##如果��时,leader��follower�U�除同步列表

replica.lag.time.max.ms=10000

##消息的备份的个数,默认�?,通常使用在replication-cluster环境�?

##kafka-cluster已经具备自动故障转移能力(>0.8V)

num.replica.fetchers=1

陕西BOY 2014-01-08 12:08 发表评论

kafka设计理论备忘

陕西BOY — Wed, 08 Jan 2014 04:01:00 GMT

kafka的设计初��h��希望作�ؓ一个统一的信息收集��^�?能够实时的收集反馈信�?�q��要能够支撑较大的数据�?且具备良好的定w��能力.

1.Persistence

kafka使用文�g存储消息,�q�就直接军_��kafka在性能上严重依赖文件系�l�的本��n�Ҏ�?且无��Z�Q何OS�?�Ҏ��件系�l�本�w�的优化几乎没有可能.文�g�~�存/直接内存映射�{�是常用的手�D?因�ؓkafka是对日志文�g�q�行append操作,因此��盘��索的开支是较小�?同时��Z��减少��盘写入的次�?broker会将消息暂时buffer��h��,当消息的个数(或尺�?辑ֈ�一定阀值时,再flush到磁�?�q�样减少了磁盘IO调用的次�?

2.Efficiency

需要考虑的媄响性能点很�?除磁盘IO之外,我们�q�需要考虑�|�络IO,�q�直接关�p�d��kafka的吞吐量问题.kafka�q�没有提供太多高��的技�?对于producer�?可以��消息buffer��h��,当消息的条数辑ֈ�一定阀值时,扚w��发送给broker;对于consumer端也是一�?扚w��fetch多条消息.不过消息量的大小可以通过配置文�g来指�?对于kafka broker�?��g��有个sendfile�pȝ��调用可以潜在的提升网�l�IO的性能:��文件的数据映射到系�l�内存中,socket直接��d��相应的内存区域即�?而无需�q�程再次copy和交�?

其实对于producer/consumer/broker三者而言,CPU的开支应该都不大,因此启用消息压羃机制是一个良好的�{�略;压羃需要消耗少量的CPU资源,不过对于kafka而言,�|�络IO更应该需要考虑.可以��Q何在�|�络上传输的消息都经�q�压�~?kafka支持gzip/snappy�{�多�U�压�~�方�?

3. Producer

Load balancing: producer��会和Topic下所有partition leader保持socket�q�接;消息由producer直接通过socket发送到broker,中间不会�l�过��M��"路由�?.事实�?消息被�\由到哪个partition�?有producer客户端决�?比如可以采用"random""key-hash""轮询"�{?如果一个topic中有多个partitions,那么在producer端实�?消息均衡分发"是必要的.

其中partition leader的位�|?host:port)注册在zookeeper�?producer作�ؓzookeeper client,已经注册了watch用来监听partition leader的变更事�?

Asynchronous send: ��多条消息暂且在客户端buffer��h��,�q�将他们扚w��发送到broker;��数据IO太多,会拖慢整体的�|�络延迟,扚w��延迟发送事实上提升了网�l�效�?不过�q�也有一定的隐患,比如当producer失效�?那些��未发送的消息��会丢失.

4.Consumer

consumer端向broker发�?fetch"��h��,�q�告知其获取消息的offset;此后consumer��会获得一定条数的消息;consumer端也可以重置offset来重新消�Ҏ��?

在JMS实现�?Topic模型��Z��push方式,即broker��消息推送给consumer�?不过在kafka�?采用了pull方式,即consumer在和broker建立�q�接之后,��d��去pull(或者说fetch)消息;�q�中模式有些优点,首先consumer端可以根据自��q��消费能力适时的去fetch消息�q�处�?且可以控制消息消费的�q�度(offset);此外,消费者可以良好的控制消息消费的数�?batch fetch.

其他JMS实现,消息消费的位�|�是有prodiver保留,以便避免重复发送消息或者将没有消费成功的消息重发等,同时�q�要控制消息的状�?�q�就要求JMS broker需要太多额外的工作.在kafka�?partition中的消息只有一个consumer在消�?且不存在消息状态的控制,也没有复杂的消息��认机制,可见kafka broker端是相当轻量�U�的.当消息被consumer接收之后,consumer可以在本��C��存最后消息的offset,�q��歇性的向zookeeper注册offset.由此可见,consumer客户端也很轻量��.

5.Message Delivery Semantics

对于JMS实现,消息传输担保非常直接:有且只有一��?exactly once).在kafka中稍有不�?

1) at most once: 最多一��?�q�个和JMS�?非持久化"消息�c�M��.发送一��?无论成��|,��不会重�?

2) at least once: 消息臛_��发送一��?如果消息未能接受成功,可能会重�?直到接收成功.

3) exactly once: 消息只会发送一��?

at most once: 消费者fetch消息,然后保存offset,然后处理消息;当client保存offset之后,但是在消息处理过�E�中出现了异�?��D��部分消息未能�l�箋处理.那么此后"未处�?的消息将不能被fetch�?�q�就�?at most once".

at least once: 消费者fetch消息,然后处理消息,然后保存offset.如果消息处理成功之后,但是在保存offset阶段zookeeper异常��D��保存操作未能执行成功,�q�就��D��接下来再�ơfetch时可能获得上�ơ已�l�处理过的消�?�q�就�?at least once".

exactly once: kafka中�ƈ没有严格的去实现(��Z��2阶段提交,事务),我们认�ؓ�q�种�{�略在kafka中是没有必要�?

通常情况�?at-least-once"是我们搜�?(相比at most once而言,重复接收数据��L��丢失数据要好).

6. Replication

kafka��每个partition数据复制到多个server�?��M��一个partition有一个leader和多个follower(可以没有);备䆾的个数可以通过broker配置文�g来设�?leader处理所有的read-write��h��,follower需要和leader保持同步.Follower和consumer一�?消费消息�q�保存在本地日志�?leader负责跟踪所有的follower状�?如果follower"落后"太多或者失�?leader��会把它从replicas同步列表中删�?当所有的follower都将一条消息保存成�?此消息才被认为是"committed",那么此时consumer才能消费�?即��只有一个replicas实例存活,仍然可以保证消息的正常发送和接收,只要zookeeper集群存活卛_��.(不同于其他分布式存储,比如hbase需�?多数�z?存活才行)

当leader失效�?需在followers中选取出新的leader,可能此时follower落后于leader,因此需要选择一�?up-to-date"的follower.选择follower旉��要兼��一个问�?��是新leader server上所已经承蝲的partition leader的个�?如果一个server上有�q�多的partition leader,意味着此server��承受着更多的IO压力.在选�D新leader,需要考虑�?负蝲均衡".

7.Log

如果一个topic的名�U�Cؓ"my_topic",它有2个partitions,那么日志��会保存在my_topic_0和my_topic_1两个目录�?日志文�g中保存了一序列"log entries"(日志条目),每个log entry格式�?4个字节的数字N表示消息的长�? + "N个字节的消息内容";每个日志都有一个offset来唯一的标��C��条消�?offset的��gؓ8个字节的数字,表示此消息在此partition中所处的起始位置..每个partition在物理存储层�?有多个log file�l�成(�U�Cؓsegment).segment file的命名�ؓ"最��offset".kafka.例如"00000000000.kafka";其中"最��offset"表示此segment中�v始消息的offset.

(摘自官网)

其中每个partiton中所持有的segments列表信息会存储在zookeeper�?

当segment文�g��寸辑ֈ�一定阀值时(可以通过配置文�g讑֮�,默认1G),��会创徏一个新的文�?当buffer中消息的条数辑ֈ�阀值时��会触发日志信息flush到日志文件中,同时如果"距离最�q�一�ơflush的时间差"辑ֈ�阀值时,也会触发flush到日志文�?如果broker失效,极有可能会丢失那些尚未flush到文件的消息.因�ؓserver意外实现,仍然会导致log文�g格式的破�?文�g��N��),那么��p��求当server启东是需要检��最后一个segment的文件结构是否合法�ƈ�q�行必要的修�?

获取消息�?需要指定offset和最大chunk��寸,offset用来表示消息的�v始位�|?chunk size用来表示最大获取消息的总长�?间接的表�C�消息的条数).�Ҏ��offset,可以扑ֈ�此消息所在segment文�g,然后�Ҏ��segment的最��offset取差�?得到它在file中的相对位置,直接��d��输出卛_��.

日志文�g的删除策略非常简�?启动一个后台线�E�定期扫描log file列表,把保存时间超�q�阀值的文�g直接删除(�Ҏ��文�g的创建时�?.��Z��避免删除文�g时仍然有read操作(consumer消费),采取copy-on-write方式.

8.Distribution

kafka使用zookeeper来存储一些meta信息,�q��用了zookeeper watch机制来发现meta信息的变更�ƈ作出相应的动�?比如consumer失效,触发负蝲均衡�{?

1) Broker node registry: 当一个kafka broker启动�?首先会向zookeeper注册自己的节点信�?临时znode),同时当broker和zookeeper断开�q�接�?此znode也会被删�?

格式: /broker/ids/[0...N] -->host:port;其中[0..N]表示broker id,每个broker的配�|�文件中都需要指定一个数字类型的id(全局不可重复),znode的��gؓ此broker的host:port信息.

2) Broker Topic Registry: 当一个broker启动�?会向zookeeper注册自己持有的topic和partitions信息,仍然是一个��时znode.

格式: /broker/topics/[topic]/[0...N] 其中[0..N]表示partition索引�?

3) Consumer and Consumer group: 每个consumer客户端被创徏�?会向zookeeper注册自己的信�?此作用主要是��Z��"负蝲均衡".

一个group中的多个consumer可以交错的消费一个topic的所有partitions;��而言�?保证此topic的所有partitions都能被此group所消费,且消�Ҏ��Z��性能考虑,让partition相对均衡的分散到每个consumer�?

4) Consumer id Registry: 每个consumer都有一个唯一的ID(host:uuid,可以通过配置文�g指定,也可以由�pȝ��生成),此id用来标记消费者信�?

格式: /consumers/[group_id]/ids/[consumer_id]

仍然是一个��时的znode,此节点的��gؓ{"topic_name":#streams...},卌��C�此consumer目前所消费的topic + partitions列表.

5) Consumer offset Tracking: 用来跟踪每个consumer目前所消费的partition中最大的offset.

格式: /consumers/[group_id]/offsets/[topic]/[broker_id-partition_id] -->offset_value

此znode为持久节�?可以看出offset跟group_id有关,以表明当group中一个消费者失�?其他consumer可以�l�箋消费.

6) Partition Owner registry: 用来标记partition被哪个consumer消费.临时znode

格式: /consumers/[group_id]/owners/[topic]/[broker_id-partition_id] -->consumer_node_id

当consumer启动�?所触发的操�?

A) 首先�q�行"Consumer id Registry";

B) 然后�?Consumer id Registry"节点下注册一个watch用来监听当前group中其他consumer�?leave"�?join";只要此znode path下节点列表变�?都会触发此group下consumer的负载均�?(比如一个consumer失效,那么其他consumer接管partitions).

C) �?Broker id registry"节点�?注册一个watch用来监听broker的存�z�L��?如果broker列表变更,��会触发所有的groups下的consumer重新balance.

1) Producer端��用zookeeper用来"发现"broker列表,以及和Topic下每个partition leader建立socket�q�接�q�发送消�?

2) Broker端��用zookeeper用来注册broker信息,已经监测partition leader存活�?

3) Consumer端��用zookeeper用来注册consumer信息,其中包括consumer消费的partition列表�{?同时也用来发现broker列表,�q�和partition leader建立socket�q�接,�q�获取消�?

陕西BOY 2014-01-08 12:01 发表评论

kafka概念备忘

陕西BOY — Wed, 08 Jan 2014 03:58:00 GMT

Kafka is a distributed, partitioned, replicated commit log service. 它提供了�c�M��于JMS的特�?但是在设计实��C��完全不同,此外它�ƈ不是JMS规范的实�?

kafka�Ҏ��息保存时�Ҏ��Topic�q�行归类,发送消息者成为Producer,消息接收者成为Consumer;此外kafka集群有多个kafka实例�l�成,每个实例(server)�U�Cؓbroker.

无论是kafka集群,�q�是producer和consumer都依赖于zookeeper来保证系�l�可用性以及保存一些meta信息.

(摘自官网)

Topics/logs

一个Topic可以认�ؓ是一�c�L��?每个topic��被分成多个partition(�?,每个partition在存储层面是append log文�g.��M��发布到此partition的消息都会直接追加到log文�g的尾�?每条消息在文件中的位�|�称为offset(偏移�?,offset��Z��个long型数�?它唯一的标��C��条消�?kafka�q�没有提供其他额外的索引机制来存储offset,因�ؓ在kafka中几乎不允许�Ҏ��息进�?随机�?�?.

(摘自官网)

kafka和JMS实现(activeMQ)不同的是:即��消息被消�?消息仍然不会被立卛_��?日志文�g��会�Ҏ��broker中的配置要求,保留一定的旉��之后删除;比如log文�g保留2�?那么两天�?文�g会被清除,无论其中的消息是否被消费.kafka通过�q�种��单的手段,来释攄��盘空�?以及减少消息消费之后�Ҏ��件内�Ҏ��动的��盘IO开�?

对于consumer而言,它需要保存消�Ҏ��息的offset,对于offset的保存和使用,有consumer来控�?当consumer正常消费消息�?offset��会"�U��?的向前驱�?��x��息将依次��序被消�?事实上consumer可以使用��L��序消费消息,它只需要将offset重置��Z�Q意�?.(offset��会保存在zookeeper�?参见下文)

kafka集群几乎不需要维护�Q何consumer和producer状态信�?�q�些信息有zookeeper保存;因此producer和consumer的客��L��实现非常轻量�U?它们可以随意��d��,而不会对集群造成额外的媄�?

partitions的设计目的有多个.最�Ҏ��原因是kafka��Z��文�g存储.通过分区,可以��日志内容分散到多个server�?来避免文件尺寸达到单机磁盘的上限,每个partiton都会被当前server(kafka实例)保存;可以��一个topic切分多�Q意多个partitions,来消息保�?消费的效�?此外��多的partitions意味着可以容纳更多的consumer,有效提升�q�发消费的能�?(具体原理参见下文).

Distribution

一个Topic的多个partitions,被分布在kafka集群中的多个server�?每个server(kafka实例)负责partitions中消息的��d��操作;此外kafka�q�可以配�|�partitions需要备份的个数(replicas),每个partition��会被备份到多台机器�?以提高可用�?

��Z��replicated�Ҏ��,那么��意味着需要对多个备䆾�q�行调度;每个partition都有一个server�?leader";leader负责所有的��d��操作,如果leader失效,那么��会有其他follower来接��?成�ؓ新的leader);follower只是单调的和leader跟进,同步消息卛_��..由此可见作�ؓleader的server承蝲了全部的��h��压力,因此从集��的整体考虑,有多��个partitions��意味着有多��个"leader",kafka会将"leader"均衡的分散在每个实例�?来确保整体的性能�E�_��.

Producers

Producer��消息发布到指定的Topic�?同时Producer也能军_��此消息归属于哪个partition;比如��Z��"round-robin"方式或者通过其他的一些算法等.

Consumers

本质上kafka只支持Topic.每个consumer属于一个consumer group;反过来说,每个group中可以有多个consumer.发送到Topic的消�?只会被订阅此Topic的每个group中的一个consumer消费.

如果所有的consumer都具有相同的group,�q�种情况和queue模式很像;消息��会在consumers之间负蝲均衡.

如果所有的consumer都具有不同的group,那这��是"发布-订阅";消息��会�q�播�l�所有的消费�?

(摘自官网)

在kafka�?一个partition中的消息只会被group中的一个consumer消费;每个group中consumer消息消费互相独立;我们可以认�ؓ一个group是一�?订阅"�?一个Topic中的每个partions,只会被一�?订阅�?中的一个consumer消费,不过一个consumer可以消费多个partitions中的消息.kafka只能保证一个partition中的消息被某个consumer消费�?消息是顺序的.事实�?从Topic角度来说,消息仍不是有序的.

kafka的设计原理决�?对于一个topic,同一个group中不能有多于partitions个数的consumer同时消费,否则��意味着某些consumer��无法得到消�?

Guarantees

1) 发送到partitions中的消息��会按照它接收的��序�q�加到日志中

2) 对于消费者而言,它们消费消息的顺序和日志中消息顺序一�?

3) 如果Topic�?replication factor"为N,那么允许N-1个kafka实例失效.

陕西BOY 2014-01-08 11:58 发表评论