zoukankan      html  css  js  c++  java
  • Kafka-常用术语(消息、生产者、消费者、集群、broker解释)

    Kafka-常用术语(消息、生产者、消费者、集群、broker解释)

    消息和批次

    kafka的数据单元被称为消息。类似于数据库表中的一行数据。

    消息由字节数组组成,所以对于kafka来说,消息里的数据没有特别的格式或含义。

    消息可以有一个可选的元数据,也就是键,键也是一个字节数组,当消息以一种可控的方式写入不同的分区时,会用到键。最简单的例子就是为键生成一个一致性散列值,然后使用散列值对主题分区数进行取模,为消息选取分区。这样可以保证具有相同键的消息总是被写到相同的分区上。

    为了提高效率,消息被分批次写入kafka。批次就是一组消息,这些消息属于同一个主题和分区。

    如果每一个消息都单独穿行于网络,会导致大量的网络开销,把消息分成批次传输可以减少网络开销。不过,这要在时间延迟和吞吐量之间做出权衡:批次越大,单位时间内处理的消息就越多,单个消息的传输时间就越长。批次数据会被压缩,这样可以提升数据的传输和存储能力,但要做更多的计算处理。

    模式

    消息模式(schema)有很多的可用选项,如:JSONXML,易用且可读性好。但是有个缺点,缺乏强类型处理能力。不同版本之间的兼容性也不是很好。

    Apache Avro,最初是为Hadoop开发的一款序列化框架。Avro提供了一种紧凑的序列化格式,模式和消息体是分开的,当模式发生变化时,不需要重新生成代码;它还支持强类型和模式金花,版本向前向后都兼容。

    数据格式的一致性对于kafka来说很重要,它消除了消息读写操作之间的耦合性。

    主题和分区

    Kafka的消息通过主题进行分类。主题好比数据库的表,或者文件系统的文件夹。主题可以被分为若干个分区,一个分区就是一个提交日志。消息以追加的方式写入分区,然后以先入先出的顺序读取。

    注意:由于一个主题一般包括几个分区,因此无法在整个主题范围内保证消息的顺序,但可以保证消息在单个分区内的顺序。

    kafka通过分区来实现数据冗余和伸缩性。分区可以分布在不同的服务器上,也就是说,一个主题可以横跨多个服务器,以此来提供比单个服务器更强大的功能。

    生产者和消费者

    kafka的客户端就是kafka系统的用户,它们被分为两种基本类型:生产者和消费者。除此之外,还有其他高级客户端API--用于数据集成的kafka Connect API和用于流式处理的kafka Streams

    生产者创建消息。在其它发布与订阅系统中,生产者可能被称为发布者或写入者。一般情况下,一个消息会被发布到一个特定的主题上。生产者在默认情况下把消息均衡地分布到主题的所有分区上,而并不关心特定消息会被写到哪个分区。不过,在某些情况下,生产者会把消息直接写到指定的分区。这通常是通过消息键和分区器来实现的,分区器为键生成一个散列值,并将其映射到指定的分区上。这样可以保证包含同一个键的消息会被写到同一个分区上。生产者也可以使用自定义的分区器,根据不同的业务规则将消息映射到分区。

    消费者读取消息。在其它发布与订阅系统中,消费者可能被称为订阅者或者读者。消费者订阅一个或多个主题,并按照消息生成的顺序读取它们。消费者通过检查消息的偏移量来区分已经读取过的消息。

    偏移量是另一种元数据,它是一个不断递增的整数值,在创建消息时,kafka会把它添加到消息里,在给定的分区里,每个消息的偏移量都是唯一的。消费者会把每个分区最后读取的消息偏移量保存在zookeeperkafka上,如果消费者关闭或重启,它的读取状态不会丢失。

    消费者是消费者群组的一部分,也就是说,会有一个或多个消费者共同读取一个主题。群组保证每个分区只能被一个消费者使用。消费者与分区之间的映射通常被称为消费者对分区的所有权关系。

    通过这种方式,消费者可以消费包含大量消息的主题。而且,如果一个消费者失效,群组里的其它消费者可以接管失效消费者的工作。

    broker和集群

    一个独立的kafka服务器被称为brokerbroker接收来自生产者的消息,为消息设置偏移量,并提交消息到磁盘保存。broker为消费者提供服务,对读取分区的请求作出响应,返回已经提交到磁盘上的消息。根据特定的硬件及其性能特征,单个broker可以轻松地处理数千个分区以及每秒百万级的消息量。

    broker是集群的组成部分。每个集群都有一个broker同时充当了集群控制器的角色(自动从集群的活跃成员总选举出来)。控制器负责管理工作:将分区分配给broker、监控broker

    在集群中,一个分区从属于一个broker,该broker被称为分区的首领。一个分区可以分配给多个broker,这个时候会发生分区的复制。这种复制机制为分区提供了消息冗余,如果有一个broker失效,其他broker可以接管领导权。不过,相关的消费者和生产者都要重新连接到新的首领。

    保留消息(在一定期限内)kafka的一个重要特性。Kafka broker默认的消息保留策略是这样:要么保留一段时间(比如7天),要么保留消息达到一定大小的字节数(比如1GB)。当消息数量达到这些上限时,旧消息就会过期并被删除,所以在任何时刻,可用消息的总量都不会超过配置参数所指定的大小。主题可以配置自己的保留策略,可以将消息保留到不再使用它们为止。

    例如:用于跟踪用户活动的数据可能需要保留几天,而应用程序的度量指标可能只需要保留几个小时。可以通过配置把主题当作紧凑型日志,只有最后一个带有特定键的消息会被保留下来。这种情况对于变更日志类型的数据来说比较适用,因为只关心最后时刻发生的那个变更。

    多集群

    随着kafka部署数量的增加,基于以下几点原因,最好使用多个集群

    1.数据类型分离

    2.安全需求隔离

    3.多数据中心(灾难恢复)

    如果使用多个数据中心,就需要在它们之间复制消息。这样,在线应用程序才可以访问到多个站点的用户活动信息。例如,如果一个用户修改了他们的资料信息,不管从哪个数据中心都应该能看到这些改动。或者多个站点的监控数据可以被聚集到一个部署了分析程序和告警系统的中心位置。不过,kafka的消息复制机制只能在单个及群里进行,不能在多个集群之间进行。

    kafka提供了一个叫做MirrorMarker的工具,可以用它来实现集群间的消息复制。MirrorMarker的核心组件包含了一个生产者和消费者,两者之间通过一个队列相连。消费者从一个集群读取消息,生产者把消息发送到另一个集群上。

    两个本地集群的消息被聚集到一个聚合集群上,然后将该集群复制到其他数据中心。

  • 相关阅读:
    python的dict和set
    python基础之dict和set
    python基础之条件判断和循环
    mongodb安装和配置,遇到问题和解决方法
    mybatis12--一级缓存
    mybatis11--多对多关联查询
    mybatis10--自连接多对一查询
    mybatis09--自连接一对多查询
    mybatis08--关联查询多对一
    mybatis07--关联查询一对多
  • 原文地址:https://www.cnblogs.com/EnzoDin/p/12562187.html
Copyright © 2011-2022 走看看