英德住房和城乡建设局网站,做 理财网站有哪些,深圳建站费用,微商如何做网站引流目录 Kafka介绍Kafka优势Kafka应用场景Kafka基本架构和概念ProducerConsumer/Consumer GroupBrokerZooKeeperTopicPartitionReplicasOffsetsegment Kafka介绍
Kafka是是一个优秀的分布式消息中间件#xff0c;关于常用的消息中间件对比可参考文章#xff1a;消息中间件概述。… 目录 Kafka介绍Kafka优势Kafka应用场景Kafka基本架构和概念ProducerConsumer/Consumer GroupBrokerZooKeeperTopicPartitionReplicasOffsetsegment Kafka介绍
Kafka是是一个优秀的分布式消息中间件关于常用的消息中间件对比可参考文章消息中间件概述。
Kafka是最初由Linkedin公司开发是一个分布式、分区的、多副本的、多生产者、多订阅者基于zookeeper协调的分布式日志系统也可以当做MQ系统常见可以用于web/nginx日志、访问日志消息服务等等Linkedin于2010年贡献给了Apache基金会并成为顶级开源项目。
Kafka主要设计目标如下
以时间复杂度为O(1)的方式提供消息持久化能力即使对TB级以上数据也能保证常数时间的访问性能。高吞吐率。即使在非常廉价的商用机器上也能做到单机支持每秒100K条消息的传输。支持Kafka Server间的消息分区及分布式消费同时保证每个分区内的消息顺序传输。同时支持离线数据处理和实时数据处理。支持在线水平扩展
有两种主要的消息传递模式点对点传递模式、发布-订阅模式。大部分的消息系统选用发布-订阅模式。Kafka就是一种发布-订阅模式。
对于消息中间件消息分推拉两种模式。Kafka只有消息的拉取没有推送可以通过轮询实现消息的推送。
Kafka具有四个核心API
Producer API允许应用程序将记录流发布到一个或多个Kafka主题。Consumer API允许应用程序订阅一个或多个主题并处理为其生成的记录流。Streams API允许应用程序充当流处理器使用一个或多个主题的输入流并生成一个或多个输出主题的输出流从而有效地将输入流转换为输出流。Connector API允许构建和运行将Kafka主题连接到现有应用程序或数据系统的可重用生产者或使用者。例如关系数据库的连接器可能会捕获对表的所有更改。
Kafka优势
高吞吐量单机每秒处理几十上百万的消息量。即使存储了许多TB的消息它也保持稳定的性能。高性能单节点支持上千个客户端并保证零停机和零数据丢失。持久化数据存储将消息持久化到磁盘。通过将数据持久化到硬盘以及replication防止数据丢失。分布式系统易于向外扩展。所有的Producer、Broker和Consumer都会有多个均为分布式的。无需停机即可扩展机器。多个Producer、Consumer可能是不同的应用。可靠性 - Kafka是分布式分区复制和容错的。客户端状态维护消息被处理的状态是在Consumer端维护而不是由server端维护。当失败时能自动平衡。支持online和offline的场景。支持多种客户端语言。Kafka支持Java、.NET、PHP、Python等多种语言。
Kafka应用场景
日志收集 一个公司可以用Kafka可以收集各种服务的Log通过Kafka以统一接口服务的方式开放给各种Consumer
消息系统 解耦生产者和消费者、缓存消息等
用户活动跟踪 Kafka经常被用来记录Web用户或者App用户的各种活动如浏览网页、搜索、点击等活动这些活动信息被各个服务器发布到Kafka的Topic中然后消费者通过订阅这些Topic来做实时的监控分析亦可保存到数据库
运营指标 Kafka也经常用来记录运营监控数据。包括收集各种分布式应用的数据生产各种操作的集中反馈比如报警和报告
流式处理 比如Spark Streaming和Storm。
Kafka基本架构和概念
kafka的整体架构如下图所示
图片来源https://mp.weixin.qq.com/s/_g11mmmQse6KrkUE8x4abQ 从大的组件上看kafka主要由Producer、Broker、Consumer 以及负责集群管理的 ZooKeeper 组成。除了极大组件整个消息的流转还涉及到还有几个特别重要的概念—主题Topic、分区Partition、分段(segment)、位移offset。
先来整体了解下基本的架构流程。
Broker创建好后会把集群的元数据存到Zookeeper中供生产者和消费者读取使用Producer负责生产消息获取Broker的元信息并把消息发送到BrokerBroker可以有不同主题TopicTopic是一个虚拟的概念Topic又可以有不同的分区Partition分区由不同的分段segment组成最后消息由Broker根据消息属性路由到了指定的主题的指定分区多个消费者Consumer可以组成消费者组Consumer Group共同消费不同分区的消息消费者获取集群的Topic等元数据并根据消息的偏移量offset来读取消息
下面来具体看下各个组件和概念。
Producer
生产者负责消息的创建并通过一定的路由策略发送消息到合适的 Broker。broker将该消息追加到当前用于追加数据的 segment 文件中。
一般情况下一个消息会被发布到一个特定的主题Topic上。
默认情况下通过轮询把消息均衡地分布到主题的所有分区上。在某些情况下生产者会把消息直接写到指定的分区。这通常是通过消息键和分区器来实现的分区器为键生成一个散列值并将其映射到指定的分区上。这样可以保证包含同一个键的消息会被写到同一个分区上。生产者也可以使用自定义的分区器根据不同的业务规则将消息映射到分区。
Consumer/Consumer Group
消费者负责从 Broker 中拉取Pull订阅的消息并进行消费通常多个消费者(Consumer)构成一个分组(Consumer Group)消费者组是为了保证同一个消息只能被一个组里一个消费者消费同时可以动态扩容。
具有如下特点
消费者组订阅一个或多个主题并按照消息生成的顺序读取它们。消费者通过检查消息的偏移量来区分已经读取过的消息。偏移量是另一种元数据它是一个不断递增的整数值在创建消息时Kafka 会把它添加到消息里。在给定的分区里每个消息的偏移量都是唯一的。消费者把每个分区最后读取的消息偏移量保存在Zookeeper 或Kafka上如果消费者关闭或重启它的读取状态不会丢失。消费者是消费组的一部分。群组保证每个分区只能被一个消费者使用。如果一个消费者失效消费组里的其他消费者可以接管失效消费者的工作再平衡分区重新分配。 消费者与消费组这种模型可以让整体的消费能力具备横向伸缩性我们可以增加(或减少) 消费者的个数来提高(或降低)整体的消费能力。对于分区数固定的情况一味地增加消费者 并不会让消费能力一直得到提升如果消费者过多出现了消费者的个数大于分区个数的情况 就会有消费者分配不到任何分区。
Broker
服务实例负责消息的持久化、中转等功能。一个独立的Kafka 服务器被就是一个broker。
broker 是集群的组成部分。每个集群都有一个broker 同时充当了集群控制器Controller的角色。在每一个Broker在启动时都会像向ZK注册信息ZK会选取一个最早注册的Broker作为Controller后面Controller会与ZK进行数据交互获取元数据即整个Kafka集群的信息例如有那些Broker,每个Broker中有那些Partition等信息并负责管理工作包括将分区分配给broker 和监控broker其他Broker是与Controller进行交互进而感知到整个集群的所有信息。
在集群中一个分区从属于一个broker该分区被称为分区的首领Leader。一个Topic的不同分区一般是分布在不同的broker中。 broker 可以为消费者提供服务对读取分区的请求作出响应返回已经提交到磁盘上的消息。
ZooKeeper
负责 broker、consumer 集群元数据的管理等
注意Producer 端直接连接 broker不在 zk 上存任何数据只是通过 ZK 监听 broker 和 topic 等信息
Topic
每条发布到Kafka集群的消息都有一个类别这个类别被称为Topic。
Kafka 按 topic 对消息进行分类我们在收发消息时只需指定 topic。
的Topic是逻辑概念并没有物理存在但是注意物理上不同Topic的消息是分开存储的。
主题就好比数据库的表尤其是分库分表之后的逻辑表。
Partition
分区。为了提升系统的吞吐一个 topic 下通常有多个 partitionpartition 分布在不同的 Broker 上用于存储 topic 的消息这使 Kafka 可以在多台机器上处理、存储消息给 kafka 提供给了并行的消息处理能力和横向扩容能力。另外为了提升系统的可靠性partition 通常会分组且每组有一个主 partition、多个副本 partition且分布在不同的 broker 上从而起到容灾的作用。
下面是分区数量和集群数量不同情况时分区的分布情况
如果某topic有N个partition集群有N个broker那么每个broker存储该topic的一个partition。如果某topic有N个partition集群有(NM)个broker那么其中有N个broker存储该topic的一个partition剩下的M个broker不存储该topic的partition数据。如果某topic有N个partition集群中broker数目少于N个那么一个broker存储该topic的一个或多个partition。在实际生产环境中尽量避免这种情况的发生这种情况容易导致Kafka集群数据不均衡。
消息以追加的方式写入分区然后以先入先出的顺序读取。 Replicas
副本。即分区的副本。上面我们说到为了提升系统的可靠性partition 通常会分组且每组有一个主 partition、多个副本 partition且分布在不同的 broker 上从而起到容灾的作用。 图中每个TopicA-x都是一个Partition其中后面的数字代表了一个分区中的第几个副本同一个分区的副本需要分布在不同的broker中。
此外我们说过多个副本Partition中会选取一个作为leader其他的作为follower。生产者在发送数据的时候是直接发送到leader partition里面然后follower partition会去leader那里自行同步数据消费者消费数据的时候也是从leader那去消费数据的。
副本处于不同的 broker 中当 leader 副本出现故障时从 follower 副本中重新选举新的 leader 副本对外提供服务。Kafka 通过多副本机制实现了故障的自动转移当 Kafka 集群中某个 broker 失效时仍然能保证服务可用。
关于如何确定副本故障和故障转移的后面还会详细介绍。
Offset
偏移量。有两个生产者偏移量也是消息存储的偏移量和消费者偏移量。
生产者Offset
即消息在日志中的位置。消息写入的时候每一个分区都有一个offset这个offset就是生产者的offset同时也是这个分区的最新最大的offset。offset 是消息在分区中的唯一标识是一个单调递增且不变的值。 有些时候没有指定某一个分区的offset这个工作kafka帮我们完成。
Kafka 通过它来保证消息在分区内的顺序性不过 offset 并不跨越分区所以Kafka 保证的是分区有序而不是主题有序。但是在需要严格保证消息的消费顺序的场景下需要将partition数目设为1。
消费者Offset
当消费者进行消费的时候是要去指分区找消息的Offset从而找到消息进行消费。他与分区的最新消息的Offset是不一样的。他是存储在消费者组中每个分区都有一个Offset用于标识当前消费者组下一个要消费消息的Offset。 如上图这是某一个分区的offset情况生产者写入的offset是最新最大的值是12而当Consumer A进行消费时从0开始消费一直消费到了9消费者的offset就记录在9Consumer B就纪录在了11。等下一次他们再来消费时他们可以选择接着上一次的位置消费当然也可以选择从头消费或者跳到最近的记录并从“现在”开始消费。
segment
分段。宏观上看一个 partition 对应一个日志Log。由于生产者生产的消息会不断追加到 log 文件末尾为防止 log 文件过大导致数据检索效率低下Kafka 采取了分段和索引机制将每个 partition 分为多个 segment同时也便于消息的维护和清理。每个 segment 包含一个.log 日志文件、两个索引(.index、timeindex)文件以及其他可能的文件。每个 Segment 的数据文件以该段中最小的 offset 为文件名当查找 offset 的 Message 的时候通过二分查找快找到 Message 所处于的 Segment 中。
参考 https://mp.weixin.qq.com/s/_g11mmmQse6KrkUE8x4abQ https://mp.weixin.qq.com/s/v6jUK8TIPi1Debfd40GU3w
