zoukankan      html  css  js  c++  java
  • KAFKA官方教程笔记-introduction

    介绍

     apache kafka是一个分布式流式处理平台,一个流式平台该有的三个关键能力:

    1. 发布、订阅流式数据。从这个角度讲类似消息队列或者企业消息系统;
    2. 容错的数据存储机制;
    3. 实时处理数据。

    kafka的优点:

    1. 在系统、应用之间创建可靠的实时流式数据管道;
    2. 创建实时流式数据处理应用。

    为了解kafka如何实现以上几点,我们深入探讨kafka能力。

    首先是了解一些概念:

    • kafka作为集群运行在一台或者多台服务器上
    • kafka按分类存储数据(被称为topic)
    • 每条数据由key,value,时间戳组成.

    一些术语

    Broker
      Kafka集群包含一个或多个服务器,这种服务器被称为broker

    • Topic
        每条发布到Kafka集群的消息都有一个类别,这个类别被称为Topic。(物理上不同Topic的消息分开存储,逻辑上一个Topic的消息虽然保存于一个或多个broker上但用户只需指定消息的Topic即可生产或消费数据而不必关心数据存于何处)Topic在逻辑上可以被认为是一个queue,每条消费都必须指定它的Topic,可以简单理解为必须指明把这条消息放进哪个queue里。为了使得Kafka的吞吐率可以线性提高,物理上把Topic分成一个或多个Partition,每个Partition在物理上对应一个文件夹,该文件夹下存储这个Partition的所有消息和索引文件。
    • Partition
        Parition是物理上的概念,每个Topic包含一个或多个Partition.每个Partition在物理上对应一个文件夹,该文件夹下存储这个Partition的所有消息和索引文件。对于一个topic,3个分区,则同一组消费者数量应当<=3,否则有消费者接受不到数据;
    • Producer
        负责发布消息到Kafka broker
    • Consumer
        消息消费者,向Kafka broker读取消息的客户端。
    • Consumer Group
        每个Consumer属于一个特定的Consumer Group(可为每个Consumer指定group name,若不指定group name则属于默认的group)。

    kafka的四个核心api

    • 生产者api
    • 消费者api
    • 流式处理api
    • 连接api,将topic连接到现有的应用程序或数据系统。

    05161732_dI6k.png

     在kafka中连通服务器和客户端使用的是简单、高效、语言无关的tcp协议。目前的协议和旧版本协议兼容,我们提供java等多语言客户端。

    Topics和Logs

     topic就是消息分类,一个topic可以有0-n个消息订阅者。

    06142423_H9HJ.png

    如图,每个分区是有序的数据连续不断的追加到日志文件结构末尾。分区中的记录被赋予一个分区内唯一的值,这个值被称作offset。

    在kafka集群中保留所有发布的数据-无论是否被消费过-通过配置设置保留时间。比如,保留策略设置为两天,那么等记录分布两天内,这条数据是可消费的,之后数据将被删除以用来释放空间。kafka读写性能稳定和数据大小无关(这个是kafka牛逼的地方)。

    05161733_g6H8.png

    实际上,消费者保留的唯一元数据就是offset,通常offset由0线性增长,但是实际上因为这个值是消费者可控的,所以可以从0开始,也可以从最新一条数据的offset开始。

    分布式

    数据的分区被集群分布在kafka的多个服务器上,每个服务器处理它分到的分区,并向共同的分区请求数据。分区数通过配置文件设置,每个分区复制数据。(这就是所谓的容错机制,和hadoop优点像)

    每个分区中有个服务器作为leader,其余0-n个服务器作为followers。leader处理所有的读写请求,其余的follow被动的复制leader的数据。如果leader服务器挂了,followers 中的一台服务器会被选举成新leader。一台服务器可能同时是一个分区的leader,另一个分区的follower。这样做到负载均衡,避免所有的请求都只让一台或少数几台服务器处理。

    如果leader不挂,followers没有存在的意义。但lead挂了时,我们需要从followers节点中选出一个主。

    note:一个topic可以有多个复制版本(replication-factor 指定具体broker数目),一个broker多个分区(partitions  数目),broker之间数据应该是相同的,而同一个broker每个分区数据应该是不一样的

    broker-0

    091202_GOdk_856051.png

    broker-1

    092000_NS4R_856051.png

    brokerid=2

    092029_inwV_856051.png

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

    100402_KB9i_856051.png

    生产者

    生产者向自己指定的topic写数据,生产者的主要职责是选择发布到topic的哪个分区。最简单的方式从分区列表中轮流选择。也可以根据某种算法依照权重选择分区。开发者负责如何选择分区的算法。
    消费者

    消费者以组名被标记,如果所有消费者共有一个消费者组名,那么记录将在消费者中高效平衡的均匀发布。如果所有消费者都使用不同的组名,那就是一个消息广播。

    05163739_oWNL.png

    2个kafka集群托管4个分区(P0-P3),2个消费者组,消费组A有2个消费者实例,消费组B有4个。

    正像传统的消息系统一样,Kafka保证消息的顺序不变。 再详细扯几句。传统的队列模型保持消息,并且保证它们的先后顺序不变。但是, 尽管服务器保证了消息的顺序,消息还是异步的发送给各个消费者,消费者收到消息的先后顺序不能保证了。这也意味着并行消费将不能保证消息的先后顺序。用过传统的消息系统的同学肯定清楚,消息的顺序处理很让人头痛。如果只让一个消费者处理消息,又违背了并行处理的初衷。 在这一点上Kafka做的更好,尽管并没有完全解决上述问题。 Kafka采用了一种分而治之的策略:分区。 因为Topic分区中消息只能由消费者组中的唯一一个消费者处理,所以消息肯定是按照先后顺序进行处理的。但是它也仅仅是保证Topic的一个分区顺序处理,不能保证跨分区的消息先后处理顺序。 所以,如果你想要顺序的处理Topic的所有消息,那就只提供一个分区。

    保证

    消息的发送顺序就是消息的保存顺序,也就是消费者接收消息的顺序。一个topic的 replication factor如果设置为n,那么即使n-1台服务器挂了,数据也不会丢失。

    • 时间复杂度为O(1)的方式提供消息持久化能力,即使对TB级以上数据也能保证常数时间的访问性能.一个持久化的队列可以构建在对一个文件的读和追加上,就像一般情况下的日志解决方案。尽管和B树相比,这种结构不能支持丰富的语义,但是它有一个优点,所有的操作都是常数时间,并且读写之间不会相互阻塞。这种设计具有极大的性能优势:最终系统性能和数据大小完全无关,服务器可以充分利用廉价的硬盘来提供高效的消息服务。 
    • 高吞吐率。即使在非常廉价的商用机器上也能做到单机支持每秒100K条消息的传输
    • 支持Kafka Server间的消息分区,及分布式消费,同时保证每个partition内的消息顺序传输
    • 同时支持离线数据处理和实时数据处理

    kefka可以作为消息系统,存储系统,流式处理系统。也可以把它们整合起来。

    转载于:https://my.oschina.net/u/856051/blog/1529423

  • 相关阅读:
    LeetCode "Median of Two Sorted Arrays"
    LeetCode "Distinct Subsequences"
    LeetCode "Permutation Sequence"

    LeetCode "Linked List Cycle II"
    LeetCode "Best Time to Buy and Sell Stock III"
    LeetCode "4Sum"
    LeetCode "3Sum closest"
    LeetCode "3Sum"
    LeetCode "Container With Most Water"
  • 原文地址:https://www.cnblogs.com/twodog/p/12139447.html
Copyright © 2011-2022 走看看