当前访客身份:游客 [ 登录  | 注册加入尚学堂]
直播

我来了!

拥有积分:4038
尚学堂雄起!!威武。。。

博客分类

笔记中心

课题中心

提问中心

答题中心

解答题中心

Kafka实现细节(上)

我来了! 发表于 2年前 (2014-11-10 17:00:44)  |  评论(0)  |  阅读次数(494)| 0 人收藏此文章,   我要收藏   

如果你第一次看kafka的文章,请先看《分布式消息系统kafka初步》

之前有人问kafka和一般的MQ之间的区别,这个问题挺难回答,我觉得不如从kafka的实现原理来分析更为透彻,这篇将依据官网上给出的design来详细的分析,kafka是如何实现其高性能、高吞吐的。这一段应该会挺长的我想分两篇来写。今天这一篇主要从宏观上说kafka实现的细节,下一篇,在从具体的技术上去分析。

我们先看kafka的设计元素:

1. 通常来说,kafka的使用是为了消息的持久化(persistent messages

2. 吞吐量是kafka设计的主要目标

3. 关于消费的状态被记录为consumer的一部分,而不是server。这点稍微解释下,这里的server还是只broker,谁消费了多少数据都记录在消费者自己手中,不存在broker中。按理说,消费记录也是一个日志,可以放在broker中,至于为什么要这么设计,我们写下去了再说。

4. Kafka的分布式可以表现在producerbrokerconsumer都可以分布在多台机器上。

在讲实现原理之前,我们还得了解几个术语:

Topic:其实官网上没有单独提这个词,但topic其实才是理解的关键,在kafka中,不同的数据可以按照不同的topic存储。

Message:消息是kafka处理的对象,在kafka中,消息是被发布到brokertopic中。而consumer也是从相应的topic中拿数据。也就是说,message是按topic存储的。

Consumer Group:虽然上面的设计元素第四条,我们说三者都可以部署到多台机器上,三者分别并作为一个逻辑的group,但对于consumer来说这样的部署需要特殊的支持。Consumer Group就是让多个(相关的)进程(机器)在逻辑上扮演一个consumer。这个group的定义其实是为了去支持topic这样的语义。在JMS中,大家最熟悉的是队列,我们将所有的consumer放到一个group中,这样就是队列。而topic则是将consumer放置到与它相关的topic中去。所以无论一个topic存在于多少个consumer中, a message is stored only a single time。你可能会有疑问,备份怎么办,接着看下去。

接下来,我们来看kafka的实现究竟依赖了哪些东西。

1.  硬件上,kafka选用了硬盘直接读写,当然这里也有策略。一个67200rpm STAT RAID5的阵列,线性读写速度是300MB/sec,如果是随机读写,速度则是50K/sec。差距很明显,所以kafka选的策略就是利用线性存储,至于怎么存,我们在存储中会说到。

2.  关于缓存,kafka没有使用内存作为缓存。操作系统用个特性,如果不用direct I/O,那些闲置的memory会去做disk caching,如果 a process maintains an in-process cache of the data,这样的情况下可能会产生双份的pagecache,会存储两遍。另外Kafka跑在JVM上,本身JVM垃圾回收、创建对象都非常的耗内存,所以不再依赖于内存做缓存。All data is immediately written to a persistent log on the filesystem without any call to flush the data. 当然内核自己的flush不算了。温泉做一次32G的内存缓存,需要大概10多分钟。

3.    Liner writer/reader:这样做的虽然没有B树那样多样的变化,但却有O1)的操作,而且读写不会相互影响。同时,线性的读写也解耦了数据规模的问题。用廉价的存储就可以达到很高的性价比。

4.    Zero-copy:将数据从硬盘写到socket一般需要经过你可以自己算一下,这是操作系统里的知识,答案在文章末尾,具体也可以看这里:http://my.oschina.net/ielts0909/blog/85147。一句话,Zero-copy减少了IO的操作步骤。

5.   GZIP and Snappy compression:考虑到传输最大的瓶颈就在于网络上,kafka提供了对数据压缩的各种协议。

6.   事务机制:虽然kafka对事务的处理比较薄弱,但是在message的分发上还是做了一定的策略来保证数据递送的准确性:

At most once—this handles the first case described. Messages are immediately marked as consumed, so they can't be given out twice, but many failure scenarios may lead to losing messages.

At least once—this is the second case where we guarantee each message will be delivered at least once, but in failure cases may be delivered twice.

Exactly once—this is what people actually want, each message is delivered once and only once.

上述就是关于kafka的实现细节,主要写了关于kafka采用到的技术和使用技术的原因,在后面一篇中,我将主要讲述producerbrokerconsumer之间的配合以及kafka的存储问题。

 --------------------------------------------------------------------------------

To understand the impact of sendfile, it is important to understand the common data path for transfer of data from file to socket:

  1. The operating system reads data from the disk into pagecache in kernel space
  2. The application reads the data from kernel space into a user-space buffer
  3. The application writes the data back into kernel space into a socket buffer
  4. The operating system copies the data from the socket buffer to the NIC buffer where it is sent over the network
其实zero-copy这个技术我们已经在使用了,在NIO中的FileChannel中的transferTo就是采用这样的原理的。

 

分享到:0
关注微信,跟着我们扩展技术视野。每天推送IT新技术文章,每周聚焦一门新技术。微信二维码如下:
微信公众账号:尚学堂(微信号:bjsxt-java)
声明:博客文章版权属于原创作者,受法律保护。如果侵犯了您的权利,请联系管理员,我们将及时删除!
(邮箱:webmaster#sxt.cn(#换为@))
北京总部地址:北京市海淀区西三旗桥东建材城西路85号神州科技园B座三层尚学堂 咨询电话:400-009-1906 010-56233821
Copyright 2007-2015 北京尚学堂科技有限公司 京ICP备13018289号-1 京公网安备11010802015183