Kafka了解一下

80人阅读 评论(0) 收藏 举报
分类:

Kafka背景

       Kafka最初是由LinkedIn公司使用Scala语言实现的,用作LinkedIn的活动流(Activity Stream)和运营数据处理管道(Pipeline)的基础。现在它已被多家不同类型的公司作为多种类型的数据管道和消息系统使用。
      领英在2011年捐赠给Apache,然后在2012年成为First-class Apache项目。

Kafka是什么?

Kafka官方定义:分布式的流媒体平台


Apache Kafka是分布式订阅、发布、消息传递的系统和强大的队列,可以处理大量数据,并使您能够将消息从一个端点传递到另一个终端。
Kafka适用于离线和在线消息消费。
Kafka消息被保留在磁盘上,并在集群内复制以防止数据丢失。
Kafka建立在ZooKeeper同步服务之上。
它与Apache Storm和Spark完美结合,实时流式传输数据分析。


Kafka优缺点

优点:
    1、高吞吐量、低延迟:kafka每秒可以处理几十万条消息,它的延迟最低只有几毫秒,每个topic可以分多个partition, consumer group 对partition进行consume操作。
    2、可扩展:Kafka集群支持热扩展,可以在集群启动后把新服务器加入到集群。
    3、容错性:允许节点失败,Kafka每个Partition数据会复制到几台服务器,当某个Broker失效时,  Zookeeper将通知生产者和消费者使用其他的Broker。
缺点:
    1、重复消息:Kafka保证每条消息至少送达一次,虽然几率很小,但一条消息可能被送达多次。
    2、消息乱序:Kafka某一个固定的Partition内部的消息是保证有序的,如果一个Topic有多个Partition,partition之间的消息送达不保证有序。
    3、复杂性:Kafka需要Zookeeper的支持,Topic一般需要人工创建,部署和维护比一般MQ成本更高。

Kafka拓扑结构





Producer:可以是web前端产生的Page View、搜索等用户活动跟踪,或者是服务器日志、系统CPU报警、警告等运营指标
Zookeeper:Kafka通过Zookeeper管理集群配置,检测partition leader存活,以及在Consumer Group发生变化时进行rebalance

名词解释

Broker:Kafka集群包含一个或多个服务器,这种服务器被称为broker
Producer:负责发布消息到Kafka broker
Topic:每条发布到Kafka集群的消息都有一个类别,这个类别被称为Topic(类似MQ中的queue)
Partition:Parition是物理上的概念,每个Topic包含一个或多个Partition
Segment:多个大小相等的段组成了一个partition,segment文件名为上一个segment文件最后一条消息的offset值。
Offset:一个连续的用于定位被追加到分区的每一个消息的序列号,最大值为64位的long大小,19位数字字符长度。
Consumer:消息消费者,向Kafka broker读取消息的客户端。
Consumer Group:每个Consumer属于一个特定的Consumer Group(可为每个Consumer指定group name,若不指定group name则属于默认的group)

Topic、partition、segment关系图



Kafka Producer

生产者将消息发送到broker上
消息的存放位置:客户端可以控制消息发送到哪个partition,有两种,一种是随机的;,一种是通过自定义函数指定partition
Kafka的批量发送:kafka支持使用批处理来提高处理效率,在配置的阀值内实现消息的批量发送

1. hash(message)% numPartition 
2.阈值可以是大小或者时间,一般是64K的大小或者10毫秒(max.message.bytes)

Kafka Consumer

消费者从broker拉取消息
Kafka也有两种模式,队列模式(Queue)和发布-订阅模式(Pub)
        队列模式:consumers可以同时争夺消息,但是只有一个consumer消费。
        发布-订阅模式:消息会被广播到consumers中,多个consumer可以加入一个consumer group,以组的身份共同竞争一个topic,topic的消息会被订阅的consumer group内的一个consumer消费。
Consumer需要维护消费的状态:消息是否被消费了,是在consumer这边记录的,这样的不会对集群和其他consumer产生影响,非常轻量级。

1.每一个consumer都是有一个consumer group的,不指定则归属默认的consumer group下。
2.发布订阅模式中,若所有的consumer都在一个consumer group中,那就是队列模式的效果。
3.消费状态是根据offset(偏移量)来确定的,类似于数组的下标。凭借offset,我们可以随心所欲的消费

Topic & Partition

Topic相当于传统MQ的queue,producer发送消息必须指定Topic
Partition(分区)出现的原因:如果一个topic对应一个文件,随着数据量的不断增大,这个文件所在的机器I/O将会成为这个topic的性能瓶颈,而partition的诞生正是为了处理这个问题:它把topic的消息拆分存储
Topic下的partition是没有上限的,根据具体业务情况来定,一般来说
        (1)Topic的partition数量大于等于broker数量,可以提高吞吐率
        (2)同一个partition的replica尽量分散到不同机器,高可用
当新加一个partition时,之前的partition数据不会变,新加的partition刚开始是空的,随后进去Topic下的message就会重新参与所有partition的load balance

1.一个topic如果有三个partition,这三个partition可能不在同一个broker上。
2.在物理结构上,每个partition对应一个物理的目录(文件夹),文件夹命名是[topicname]_[partition]_[序号]
3.Partition的数量:在创建Topic的时候指定

Topic的解剖图


1.单个Partition内部是有序的,多个partition不保证有序
2.多个Partition内的消息数量并不保证一致

Partition & Replica

       为了实现故障自动转移,Kafka在0.8版本之后,针对partition增加了Replica(副本)。每个partition可以在其他broker节点存副本,以便某个broker宕机不会影响集群。
       存replica副本的方式是按照broker的顺序存的,比如:有5个kafka broker,某个topic有3个partition,每个partition存2个副本,那么partition1存broker1和broker2,partition2存broker2和broker3,以此类推
       副本数最大,安全系数越高,但是性能越低;副本数少的话,安全系数较低。

1.Kafka副本数不能大于broker数
2.Replica的数量:在创建Topic的时候指定(副本数量是包括本身的)


副本分配图


假设集群一共有4个brokers,一个topic有4个partition,每个Partition有3个副本。下图是每个Broker上的副本分配情况。


Controller机制

        在Kafka早期,对于分区的状态管理依赖ZK的Watcher,每个broker都要在ZK上注册Watcher,所以ZK会出现太多的Watcher。假如某个broker宕机,而这个宕机的broker上又有很多partition的话,就会造成很多watcher的触发,造成集群内大规模调整。这种设计容易出现羊群效应和ZK集群过敏
        KafkaController作为kafka集群的控制者,有且存在一个leader,若干个follower,leader处理所有的读和写操作,然后副本到followers。这样ZK的压力会减小很多
Controller的职责:更新元数据、创建删除topic的行动执行等

官网的一段描述:we elect one of the brokers as the “controller”. This controller detects failures at the broker level and is responsible for changing the leader of all affected partitions in a failed broker. (controller在broker级别就检测出故障,并且负责更改故障broker内的受影响的partition的leader)

Leader机制


       和controller机制类似,不能一股脑的把所有节点的监听压力都放到ZK上,也不适合把压力放到controller上面,因为controller的压力已经很大了,所以出现了leader机制。
在Kafka中发生复制时确保partition的日志能有序地写到其他节点上,N个replicas中,其中一个replica为leader,其他都为follower, leader处理partition的所有读写请求,与此同时,follower会被动定期地去复制leader上的数据。
官网的一段描述:Each partition has one server which acts as the "leader" and zero or more servers which act as "followers". The leader handles all read and write requests for the partition while the followers passively replicate the leader. 

ISR副本同步队列

       ISR (In-Sync Replicas),这个是指副本同步队列,是由Kafka维护的列表,往partition写入一条消息,只有被ISR列表中的所有副本写入,才会被视为已提交。在leader发生故障或者宕机的时候,就会在ISR列表选举出一个新的leader(ISR状态存储在ZK)
       消息延迟的处理:followers从leader同步消息会有一定延迟(延迟时间和延迟条目 ,新版的0.10.x只支持延迟时间,不支持延迟条目),超出阈值则会被剔除出ISR。
新版为什么移除ISR的“延迟条目”机制?


1。容易被误伤。假如延迟条目设置为10,如果流量高峰,producer一次性发送20条消息到broker,在leader接收到消息而又未同步到followers的那个时间区间,如果被检测到未同步消息,那就会被移除ISR,而实际上该follower是存活的且性能没问题的。
2。无法给出一个适合的值。“延迟条目”是全局的,设置太大了,会影响真正“落后”follower的移除;设置小了,导致follower频繁的进出ISR列表。
3。延迟时间(replica.lag.time.max.ms)是10秒

Leader的选举

Kafka是在ISR列表顺序选择一个副本。
为什么不使用少数服从多数的方法?
           少数服从多数是一种比较常见的Leader选举法,要求超过半数的投票。
     这种方法冗余度较高,比如:如果容忍二台机器失败,则需要五台机器。
     而使用Kafka的这种方式,则只需要三台机器。
极端情况:假如所有的ISR副本都宕机了,该肿么办?

Kafka提供了两种方案,一种是:等待ISR列表中的副本复活;另一种是:选择一个立即可用的,但是不一定在ISR列表中的副本。
前者保持了一致性,但是,可能需要等待很长时间;后者不需要等待很长时间,但是,又无法保证一致性(高可用性和强一致性的二选一)
kafka默认后者(unclean.leader.election.enable=true)


Ack机制

 Kafka保证消息的送达,提供了三种ACK级别
      1:当ack=0,这意味着producer发送出消息即送达,不等待服务器的确认。这种情况下数据传输效率最高,但是数据可靠性确是最低的。
      2:当ack=1,表示producer写leader成功,broker就返回成功,没有等待所有
  followers写入成功(默认)
       3:当ack=-1,producer需要等待ISR中的所有副本都确认接收到数据后才算一
   次发送完成,可靠性最高。但是这样也不能100%保证数据不丢失,比如当ISR中只有一个leader时(ISR中的成员由于某些情况会增加也会减少,可能最少就只剩一个leader),这样就变成了ack=1的情况

1。当ack=1,一旦有某个broker宕机导致Partition Follow和leader切换,可能会导致丢数据
2。如果一定要高可靠性,则设置ack=-1且同时设置最小副本数大于1
3。若不满足ACK,produc会抛出异常 NotEnoughReplicas or NotEnoughReplicasAfterAppend


kafka基本安装和使用

启动ZK
zookeeper-server-start ../../config/zookeeper.properties
启动kafka
kafka-server-start ../../config/server.properties


创建topic
kafka-topics --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --create --topic myTopic
删除指定topic
kafka-topics --zookeeper localhost:2181  --delete --topic topic-test
查看已创建的topic列表
kafka-topics --zookeeper localhost:2181 --list
查看topic的信息
kafka-topics --zookeeper localhost:2181 --describe --topic myTopic


进入指定Topic的 消费控制台
kafka-console-consumer --bootstrap-server localhost:9092 --topic myTopic --from-beginning
进入指定Topic的 生产控制台
kafka-console-producer --broker-list localhost:9092 --topic myTopic

查看评论

认识kafka

kafka是一个分布式的消息队列由scala编写,不同于传统的一些消息队列,kafka的设计理念与众不同。 1、kafka的特点 。快速 单台kafka的broker实例能够支撑几千台机器每秒几百兆字...
  • tangyongzhe
  • tangyongzhe
  • 2015-05-17 23:34:02
  • 1553

Java - 介绍一下你了解的Java领域的Web Service框架。

Java领域的Web Service框架很多,包括Axis2(Axis的升级版本)、Jersey(RESTful的Web Service框架)、CXF(XFire的延续版本)、Hessian、Turm...
  • chimomo
  • chimomo
  • 2017-11-06 10:22:35
  • 281

kafka是什么?深刻理解kafka

背景介绍 Kafka简介 Kafka是一种分布式的,基于发布/订阅的消息系统。主要设计目标如下: 以时间复杂度为O(1)的方式提供消息持久化能力,并保证即使对TB级以上数据也能保证常...
  • chenxun2009
  • chenxun2009
  • 2017-09-29 05:23:54
  • 446

kafka 为什么快

一般的 mq 每个消息都有一个状态,这样每个消息状态改变都要更新,增加了很多随机读写。Kafka 对每个 partition 只有一个指针,而不是保存每个消息的状态,所有在指针后面的消息都是被消费过...
  • hotdust
  • hotdust
  • 2018-03-25 16:21:42
  • 51

kafka详解一、Kafka简介

背景:      当今社会各种应用系统诸如商业、社交、搜索、浏览等像信息工厂一样不断的生产出各种信息,在大数据时代,我们面临如下几个挑战: 如何收集这些巨大的信息如何分析它       如何及时做...
  • suifeng3051
  • suifeng3051
  • 2014-08-18 10:45:54
  • 9073

Java - 简述一下你了解的设计模式。

所谓设计模式,就是一套被反复使用的代码设计经验的总结(情境中一个问题经过证实的一个解决方案)。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。设计模式使人们可以更加简单方便的复用...
  • chimomo
  • chimomo
  • 2017-11-03 10:03:38
  • 520

简述JAVA的几种设计模式

一、工厂模式 参考文章:
  • yanjiee
  • yanjiee
  • 2014-05-19 21:43:02
  • 809

初步了解大数据概念

大数据的全局概念以及国内的一些细分的应用。
  • qq_26270367
  • qq_26270367
  • 2016-07-02 14:39:12
  • 369

加密解密你了解多少?

这个题目一写出来,笔者自己也思考了下自己在以前职业生涯中涉及到的加密解密技术,也思考了自己熟知的公知度高的几种加密方式。       下面我来说说一些理解上的东西。       加密解密中间参与的...
  • linksafe2014
  • linksafe2014
  • 2016-03-11 13:21:05
  • 701

kafka解决的问题

假设你意气风发,要开发新一代的互联网应用,以期在互联网事业中一展宏图。借助云计算,很容易开发出如下原型系统: Web应用:部署在云服务器上,为个人电脑或者移动用户提供的访问体验。 SQL数据库:为W...
  • ExceptionMapping
  • ExceptionMapping
  • 2017-11-16 17:54:00
  • 177
    个人资料
    专栏达人 持之以恒
    等级:
    访问量: 29万+
    积分: 4279
    排名: 8824
    给我写信
    博客专栏