赞
踩
在大数据中,会使用到大量的数据。面对这些海量的数据,我们一是需要做到能够收集这些数据,其次是要能够分析和处理这些海量数据。在此过程中,需要一套消息系统。
Kafka专门为分布式高吞吐量系统设计。作为一个消息代理的替代品,Kafka往往做的比其他消息中间件做的更好。
与其他消息队列产品相比,它主要有以下优点:
因此,Kafka非常适合大规模的消息处理应用。
消息系统负责将数据从一个应用传递到另一个应用,应用就可以专注于数据,而不用担心数据如何共享。分布式消息传递基于可靠消息队列的概念。消息在客户端应用程序和消息传递系统之间异步排队。
有两种类型的消息模式可用:
在点对点的消息传递类型中,所有的消息都保留在消息队列中。一个或多个消费者可以消耗队列中的消息,但特定的消息只能有最多一个消费者消费。一旦消费者消费了队列中的消息,该消息将会在消息队列中消失。
点对点消息系统最典型的例子是订单处理系统,其中每个订单将有由订单处理器处理,但多个订单处理器也可以同时工作。
在发布-订阅系统中,消息被保留在各个主题中。
与点对点系统不同的是,一个订阅者可以订阅一个或多个不同主题中的消息并使用这些主题中的所有消息。
在发布-订阅系统中,消息的生产者称为发布者,消息的使用者称为订阅者。
一个现实的例子是dish天线电视,它发布不同的渠道和主题,如运动、音乐、电影等,任何人都可以订阅自己需要的主题集,并接收到订阅主题的消息。
Kafka is a distributed,partitioned,replicated commit logservice.
Kafka非常快,并且能保证零停机和零数据丢失
小结Kafka:
分布式和分区:distributed、partitioned
Kafka是一个分布式的发布-订阅消息队列,主要体现在哪些方面?
体现在大量的数据被保存在磁盘上,但单个磁盘的容量是有限的,于是消息被生产者生产的时候分为不同的topic主题来保存,每个topic又被分为多个partition分区,而每个partition分区对应一个文件,以文件的方式来保存消息数据,每个文件又可以被保存在不同的broker上,这样就实现了Kafka集群来分布式存储消息队列。
另外,每个partition都有一定的副本,可以备份到不同的borker上,从而提高可用性。
总的来说就是,一个topic对应的多个partition上的文件分散保存在集群的多个不同broker上,存储的方式是一个partition对应一个文件,每个broker负责存储在自己机器上的每个文件的读写。
副本:replicated
Kafka可以通过配置指定partition的备份个数(replicas),每个partition将会被备份到多台机器上,提高了可用性,备份数量通过配置文件可以指定。
实质上,冗余备份在分布式系统中很常见。
有副本的存在,就会涉及到同一个文件的多个副本如何管理和调度。
Kafka设置了“leader机制”,每个partition选举一个broker作为leader,用来负责对该分区的读写,其余broker则作为follower,只需简单地和leader同步即可。如果原来的leader失效,partition则会选举新的broker成为leader。
至于如何选取 leader,实际上如果我们了解 ZooKeeper,就会发现其实这正是 Zookeeper 所擅长的,Kafka 使用 ZK 在 Broker 中选出一个 Controller,用于 Partition 分配和 Leader 选举。
实际上,作为leader的server,承担了整个分区的所有读写请求,负担是比较大的。从整体考虑,有多少个partition就有多少个leader,Kafka将leader分摊到不同的broker上,也算是整体上的一种负载均衡。
Kafka数据流处理
(1)数据产生方式:produce
生产者写入消息数据可以指定4个参数,分别为topic,partition,key,value。其中topic和value(要写入的数据)必须指定,而key和partition是可选的。
对于一条记录,要先对其进行序列化,再按照topic和partition,发送到对应的队列中去。如果没有指定partition,有两种情况:
指定key,按照key进行哈希,同一个key的消息进一个partition
未指定key, round-robin进行partition的选择
producer将会和topic下的每个partiton leader保持socket连接,消息由producer直接发送给broker。
其中partition leader的身份在zookeeper中已经注册,producer作为zookeeper client,已经注册了watch用来监听partition leader的变更事件,因此可以准确知道leader是谁。
producer端采用异步发送,先将一部分的消息存在客户端的buffer里,并将其分批发送给broker,小数据io很多会增加整体网络的延迟,批量延迟发送实际上是提供了网络效率。
(2)数据消费过程:custome
对于消费者,不是以单独形式存在的,每个消费者都属于一个消费群租customer group,一个group包含多个consumer。需要注意的是,消费者的订阅topic行为都是以customer group的形式来订阅的,发送到topic的消息,只会被订阅该topic的每个group中的每个customer消费。
如果说所有的customer都有共同的group,那么就像是一个点对点的消息系统;如果每个消费者都属于不同的group,那么消息会广播给所有的消费者。
实际上消息是根据partition来分的,一个partition只能被消费组里的一个消费者消费,但是可以多个不同的消费组消费,消费组里的每个消费者是关联到一个partition的;因此有一个说法:对同一个topic,同一个group中不能有多于partitions个数的customer同时消费,否则某些customer将无法得到消息。
同一个消费组的两个customer不能同时消费一个partition
partition 中的消息只有一个 consumer 在消费,且不存在消息状态的控制,也没有复杂的消息确认机制,可见katka broker 端是相当轻量级的。当消息被 consumer 接收之后,需要保存 Offset 记录消费到哪,以前保存在ZK中,由于 ZK 的写性能不好,以前的解决方法都是Consumer 每隔一分钟上报一次,在0.10 版本后,Kafka 把这个Offset 的保存,从ZK 中剥离,保存在一个名叫 consumeroffsets topic 的Topic 中,由此可见consumer 客户端也很轻量级
Kafka可以在很多场景中使用,以下列出一些用例:
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。