注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

记录~~~

Stay Hungry. Stay Foolish.

 
 
 

日志

 
 

Kafka  

2014-06-11 13:49:37|  分类: 读书笔记 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |
Kafka是一个高吞吐量分布式消息系统。linkedin开源的kafka。 Kafka就跟这个名字一样,设计非常独特。首先,kafka的开发者们认为不需要在内存里缓存什么数据,操作系统的文件缓存已经足够完善和强大,只要你 不搞随机写,顺序读写的性能是非常高效的。kafka的数据只会顺序append,数据的删除策略是累积到一定程度或者超过一定时间再删除。
Kafka另 一个独特的地方是将消费者信息保存在客户端而不是MQ服务器,这样服务器就不用记录消息的投递过程,每个客户端都自己知道自己下一次应该从什么地方什么位 置读取消息,消息的投递过程也是采用客户端主动pull的模型,这样大大减轻了服务器的负担。Kafka还强调减少数据的序列化和拷贝开销,它会将一些消 息组织成Message Set做批量存储和发送,并且客户端在pull数据的时候,尽量以zero-copy的方式传输,利用sendfile(对应java里的 FileChannel.transferTo/transferFrom)这样的高级IO函数来减少拷贝开销。可见,kafka是一个精心设计,特定于 某些应用的MQ系统,这种偏向特定领域的MQ系统我估计会越来越多,垂直化的产品策略值的考虑。

Kafka存储策略

1.  kafkatopic来进行消息管理,每个topic包含多个partition),每个part对应一个逻辑log,有多个segment组成。

2.  每个segment中存储多条消息(见下图),消息id由其逻辑位置决定,即从消息id可直接定位到消息的存储位置,避免id到位置的额外映射。

3.  每个part在内存中对应一个index,记录每个segment中的第一条消息偏移。

4.  发布者发到某个topic的消息会被均匀的分布到多个part上(随机或根据用户指定的回调函数进行分布),broker收到发布消息往对应part的最后一个segment上添加该消息,当某个segment上的消息条数达到配置值或消息发布时间超过阈值时,segment上的消息会被flush到磁盘,只有flush到磁盘上的消息订阅者才能订阅到,segment达到一定的大小后将不会再往该segment写数据,broker会创建新的segment


PUB:
发布消息时,kafka client先构造一条消息,将消息加入到消息集set中(kafka支持批量发布,可以往消息集合中添加多条消息,一次行发布),send消息时,client需指定消息所属的topic

SUB
订阅消息时,kafka client需指定topic以及partition num(每个partition对应一个逻辑日志流,如topic代表某个产品线,partition代表产品线的日志按天切分的结果),client订阅后,就可迭代读取消息,如果没有消息,client会阻塞直到有新的消息发布。consumer可以累积确认接收到的消息,当其确认了某个offset的消息,意味着之前的消息也都已成功接收到,此时broker会更新zookeeper上地offset registry(后面会讲到)

高效的数据传输

1.  发布者每次可发布多条消息(将消息加到一个消息集合中发布), sub每次迭代一条消息。

2.  不创建单独的cache,使用系统的page cache。发布者顺序发布,订阅者通常比发布者滞后一点点,直接使用linuxpage cache效果也比较后,同时减少了cache管理及垃圾收集的开销。

3.  使用sendfile优化网络传输,减少一次内存拷贝。

 

无状态broker

1.  Broker没有副本机制,一旦broker宕机,该broker的消息将都不可用。

2.  Broker不保存订阅者的状态,由订阅者自己保存。

3.  无状态导致消息的删除成为难题(可能删除的消息正在被订阅),kafka采用基于时间的SLA(服务水平保证),消息保存一定时间(通常为7天)后会被删除。

4.  消息订阅者可以rewind back到任意位置重新进行消费,当订阅者故障时,可以选择最小的offset进行重新读取消费消息。

 

Consumer group

1. 允许consumer group(包含多个consumer,如一个集群同时消费)对一个topic进行消费,不同的consumer group之间独立订阅。

2. 为了对减小一个consumer group中不同consumer之间的分布式协调开销,指定partition为最小的并行消费单位,即一个group内的consumer只能消费不同的partition

 

Zookeeper 协调控制

1. 管理brokerconsumer的动态加入与离开。

2. 触发负载均衡,当brokerconsumer加入或离开时会触发负载均衡算法,使得一

   个consumer group内的多个consumer的订阅负载平衡。

3.  维护消费关系及每个partion的消费信息。


Zookeeper上的细节:

1. 每个broker启动后会在zookeeper上注册一个临时的broker registry,包含brokerip地址和端口号,所存储的topicspartitions信息。

2. 每个consumer启动后会在zookeeper上注册一个临时的consumer registry:包含consumer所属的consumer group以及订阅的topics

3. 每个consumer group关联一个临时的owner registry和一个持久的offset registry。对于被订阅的每个partition包含一个owner registry,内容为订阅这个partitionconsumer id;同时包含一个offset registry,内容为上一次订阅的offset

 

消息交付保证

1. kafka对消息的重复、丢失、错误以及顺序型没有严格的要求。

2. kafka提供at-least-once delivery,即当consumer宕机后,有些消息可能会被重复delivery

3. 因每个partition只会被consumer group内的一个consumer消费,故kafka保证每个partition内的消息会被顺序的订阅。

4. Kafka为每条消息为每条消息计算CRC校验,用于错误检测,crc校验不通过的消息会直接被丢弃掉。

 

Linkedin的应用环境

如下图,左边的应用于日志数据的在线实时处理,右边的应用于日志数据的离线分析(现将日志pullhadoopDWH中)。

如下图,左边的应用于日志数据的在线实时处理,右边的应用于日志数据的离线分析(现将日志pullhadoopDWH中)。

Kafka - Goith - Web开发

 

 

Kafka的性能

 

测试环境: 2 Linux machines, each with 8 2GHz cores,  16GB  of  memory,  6  disks  with  RAID  10.  The  two machines  are  connected  with  a  1Gb  network  link.  One  of  the machines was used as the broker and the other machine was used as the producer or the consumer.

 

测试评价(by me):(1)环境过于简单,不足以说明问题。(2)对于producer持续的波动没有进行分析。(3)只有两台机器zookeeper都省了??

 

测试结果:如下图,完胜其他的message queue,单条消息发送(每条200bytes,能到50000messages/sec50batch方式发送,平均为400000messages/sec.

Kafka - Goith - Web开发

Kafka未来研究方向

1. 数据压缩(节省网络带宽及存储空间)

2. Broker多副本

3. 流式处理应用

参考资料:

http://kafka.apache.org/


  评论这张
 
阅读(355)| 评论(0)
推荐 转载

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017