高性能消息系统——Kafka

标签: 性能 消息 系统 | 发表时间:2014-06-24 13:51 | 作者:liyonghui160com
出处:http://www.iteye.com

 

什么是Kafka?
引用官方原文: “Kafka is a distributed, partitioned, replicated commit log service.”
它提供了一个非常特殊的消息机制,不同于传统的mq。
官网:https://kafka.apache.org
它与传统的mq区别?

    更快!单机上万TPS
    传统的MQ,消息被消化掉后会被mq删除,而kafka中消息被消化后不会被删除,而是到配置的expire时间后,才删除
    传统的MQ,消息的Offset是由MQ维护,而kafka中消息的Offset是由客户端自己维护
    分布式,把写入压力均摊到各个节点。可以通过增加节点降低压力

基本术语
为方便理解,我用对比传统MQ的方式阐述这些基本术语。
Producer
Consumer
这两个与传统的MQ一样,不解释了
Topic
Kafka中的topic其实对应传统MQ的channel,即消息管道,例如同一业务用同一根管道
Broker
集群中的KafkaServer,用来提供Partition服务
Partition
假如说传统的MQ,传输消息的通道(channel)是一条双车道公路,那么Kafka中,Topic就是一个N车道的高速公路。每个车道都可以行车,而每个车道就是Partition。

    一个Topic中可以有一个或多个partition。
    一个Broker上可以跑一个或多个Partition。集群中尽量保证partition的均匀分布,例如定义了一个有3个partition的topic,而只有两个broker,那么一个broker上跑两个partition,而另一个是1个。但是如果有3个broker,必然是3个broker上各跑一个partition。
    Partition中严格按照消息进入的顺序排序
    一个从Producer发送来的消息,只会进入Topic的某一个Partition(除非特殊实现Producer要求消息进入所有Partition)
    Consumer可以自己决定从哪个Partition读取数据

Offset
单个Partition中的消息的顺序ID,例如第一个进入的Offset为0,第二个为1,以此类推。传统的MQ,Offset是由MQ自己维护,而kafka是由client维护

Replica
Kafka从0.8版本开始,支持消息的HA,通过消息复制的方式。在创建时,我们可以指定一个topic有几个partition,以及每个partition有几个复制。复制的过程有同步和异步两种,根据性能需要选取。正常情况下,写和读都是访问leader,只有当leader挂掉或者手动要求重新选举,kafka会从几个复制中选举新的leader。
Kafka会统计replica与leader的同步情况。当一个replica与leader数据相差不大,会被认为是一个"in-sync" replica。只有"in-sync" replica才有资格参与重新选举。

ConsumerGroup
一个或多个Consumer构成一个ConsumerGroup,一个消息应该只能被同一个ConsumerGroup中的一个Consumer消化掉,但是可以同时发送到不同ConsumerGroup。
通常的做法,一个Consumer去对应一个Partition。
传统MQ中有queuing(消息)和publish-subscribe(订阅)模式,Kafka中也支持:

    当所有Consumer具有相同的ConsumerGroup时,该ConsumerGroup中只有一个Consumer能收到消息,就是queuing模式
    当所有Consumer具有不同的ConsumerGroup时,每个ConsumerGroup会收到相同的消息,就是publish-subscribe模式

基本交互原理
每个Topic被创建后,在zookeeper上存放有其metadata,包含其分区信息、replica信息、LogAndOffset等
默认路径/brokers/topics/<topic_id>/partitions/<partition_index>/state
Producer可以通过zookeeper获得topic的broker信息,从而得知需要往哪写数据。
Consumer也从zookeeper上获得该信息,从而得知要监听哪个partition。


基本CLI操作
1. 创建Topic
./kafka-create-topic.sh --zookeeper 10.1.110.21:2181 --replica 2 --partition 3 --topic test
2. 查看Topic信息
./kafka-list-topic.sh --topic test --zookeeper 10.1.110.24:2181
3. 增加Partition
./kafka-add-partitions.sh --partition 4 --topic test --zookeeper 10.1.110.24:2181
更多命令参见:https://cwiki.apache.org/confluence/display/KAFKA/Replication+tools


创建一个Producer
Kafka提供了java api,Producer特别的简单,举传输byte[] 为例
[java] view plaincopyprint?在CODE上查看代码片派生到我的代码片

    Properties p = new Properties(); 
    props.put("metadata.broker.list", "10.1.110.21:9092"); 
    ProducerConfig config = new ProducerConfig(props); 
    Producer producer = new Producer<String, byte[]>(config); 
    producer.send(byte[] msg); 


更具体的参见:https://cwiki.apache.org/confluence/display/KAFKA/0.8.0+Producer+Example

创建一个Consumer
Kafka提供了两种java的Consumer API:High Level Consumer和Simple Consumer
看上去前者似乎要更牛B一点,事实上,前者做了更多的封装,比后者要Simple的多……
具体例子我就不写了,参见
High Level Consumer: https://cwiki.apache.org/confluence/display/KAFKA/Consumer+Group+Example
Simple Consumer: https://cwiki.apache.org/confluence/display/KAFKA/0.8.0+SimpleConsumer+Example

 

快速学习:http://kafka.apache.org/07/quickstart.html





已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [性能 消息 系统] 推荐:

高性能消息系统——Kafka

- - 互联网 - ITeye博客
引用官方原文: “Kafka is a distributed, partitioned, replicated commit log service.”. 它提供了一个非常特殊的消息机制,不同于传统的mq. 官网:https://kafka.apache.org.     传统的MQ,消息被消化掉后会被mq删除,而kafka中消息被消化后不会被删除,而是到配置的expire时间后,才删除.

Jafka - 一个高性能的消息系统

- - BlogJava-首页技术区
Jafka 是一个高性能的分布式消息系统. Jafka已经开源,使用github托管,主页地址: https://github.com/adyliu/jafka. Jafka 1.0版本已经发布,同步到Maven中央仓库. Jafka是由Apache孵化的Kafka(由LinkedIn捐助给Apache)克隆而来.

常见开源消息系统

- - Web 开发 : 从后端到前端
消息系统的作用:异步处理、削减峰值、减少组件之间的耦合. 选择消息系统根据业务需要需要考虑以下几个方面:. 其他,如消息丢失和重复的处理. 类似 MEMCACHE 的协议. 1、2 是不错的可选开源组件:. Kafka/MetaQ: 广泛用于 Linkedin 内部 (类似有 Java 版本的国产 MetaQ).

分布式消息系统:Kafka

- - 标点符
Kafka是分布式发布-订阅消息系统. 它最初由LinkedIn公司开发,之后成为Apache项目的一部分. Kafka是一个分布式的,可划分的,冗余备份的持久性的日志服务. 在大数据系统中,常常会碰到一个问题,整个大数据是由各个子系统组成,数据需要在各个子系统中高性能,低延迟的不停流转. 传统的企业消息系统并不是非常适合大规模的数据处理.

kafka分布式消息系统

- - CSDN博客云计算推荐文章
Kafka[1]是linkedin用于日志处理的分布式消息队列,linkedin的日志数据容量大,但对可靠性要求不高,其日志数据主要包括用户行为(登录、浏览、点击、分享、喜欢)以及系统运行日志(CPU、内存、磁盘、网络、系统及进程状态). 当前很多的消息队列服务提供可靠交付保证,并默认是即时消费(不适合离线).

高性能建站系统

- - 互联网 - ITeye博客
首先是从三方面来提高的,应用层面,服务器端层面,数据库层面. 1、采用freemaker或者velocity来做页面静态化,提高网站的访问速度. 1、对于一些不经常增删改的数据做缓存,比如memcached,redis,mongodb. 2、对于图片的话,采用fastDFS来做图片的分布式服务器,加快图片的存储与读取.

linux 系统性能指标

- - 非技术 - ITeye博客
近段时间,再忙着找实习,经常被问到的,关于linux系统性能的指标,比如对于一台linux机器来说,怎么监控它的CPU,内存,负载等情况;怎样算高负载,具体的依据是什么. 等等这类问题,下面就好好总结一下这方面知识吧~. 由于能力有限,可能总结的不是很全面,不是很正确,有错漏的,欢迎大家帮忙指出,谢谢.

手机系统消息通知设计的整理和分析

- Hu DongHai - 信息和交互 - UCD大社区
当应用程序不处于前台运行中时,消息通知能将某些信息及时告知用户. 比如收到新消息、收到新邮件、程序下载已完成或者待办事项即将开始等. 目前各移动平台上对消息通知的设计均有所差别,各有利弊. 这里整理了iOS、Android、Palm Web OS、Windows Phone和未揭开面纱的Meego这五个系统对消息通知的处理方式,并分析了它们各自的优缺点.

Tumblr的消息通知系统是如何构建的

- - 博客园_旁观者-郑昀
Tumblr是世界上最流行的轻博客服务之一,2007年成立. 一,MySQL+Memcached. 初期,其通知系统是由 MySQL+Memcached 的传统架构组成. MySQL负担重,表象就是 MySQL 并发事务数常常达到 InnoDB global transaction 最大值,即只能有1023个并发事务(注:特指  mysql5.0/5.1存在的问题,5.5.4以上版本修复).

即时消息应用颠覆移动生态系统格局

- - 互联网的那点事
消息应用是手机的一项重要功能,以短信为主导的消息服务已经发展成一项规模庞大的产业,为全球移动运营商带来了丰厚的收益,预计未来三年消息产业的年营收将达1400亿美元. 不过,一批新兴企业开始推出的OTT消息服务——不依赖无线蜂窝网络,直接在互联网上发送即时消息的服务——正在改变移动生态系统的格局. 从提供Messenger服务的Facebook到位于美国加州圣克拉拉的初创公司WhatsApp——WhatsApp月活跃用户达2亿,以及Twitter和韩国的LINE,他们已经成为抢夺移动用户的最大OTT消息服务提供商,不仅对移动运营商构成威胁,而且还对社交媒体构成威胁.