kafka（一）：介绍和架构、应用场景和同类型比对

最新推荐文章于 2023-04-26 11:55:10 发布

羽落风起

最新推荐文章于 2023-04-26 11:55:10 发布

阅读量615

点赞数

分类专栏： kafka 大数据文章标签： kafka 大数据

本文链接：https://blog.csdn.net/qq_22973811/article/details/115008468

版权

大数据同时被 2 个专栏收录

53 篇文章 4 订阅

订阅专栏

kafka

6 篇文章 0 订阅

订阅专栏

说明

当前大数据开发流程，从最初的批处理到流处理再到流批一体，技术方案也从MapReduce到spark在到flink，那么如何将实时数据稳定、高效、灵活的传送到计算引擎里呢，这里必须使用到分布式消息引擎kafka。

kafka简介

什么是kafka

kafka最初由LinkedIn使用Scala进行开发，后来使用Java重写Producer API、Consumer API，2011年初加入Apache开源项目，2012年10月从Apache Incubator毕业，成为Apache顶级项目，即Apache Kafka。
kafka独立于hadoop之外，支持独立和分布式安装，分布式控制中心统一由zookeeper担任，所以安装时，必须安装zookeeper。
官网

kafka高吞吐率实现

为了增加存储能力，Kafka将所有的消息都写入到了低速大容量的硬盘。Kafka采用以下方式实现高吞吐率：
- 顺序读写：Kafka将消息顺序追加到Partition中，顺序读写要快于随机读写。
- Zero Copy：Kafka的生产者、消费者API对于Kafka消息采用零拷贝实现。Java类库通过java.nio.channels.FileChannel中的transferTo()方法(底层sendfile系统调用)在Linux和UNIX系统上支持Zero Copy，内核直接将数据从磁盘文件拷贝到Socket套接字，而无需通过应用程序。
- 批量发送：Kafka允许批量发送模式。
- 消息压缩：Kafka允许对消息集合进行压缩。
- 操作系统页缓存：不直接写IO，直接写入页缓存；消费时大多命中缓存。

kafka消息传递模式

点对点模型

基于拉取或轮询的消息传送模型，由消费者主动拉取数据，客户端需要持续开启独立线程监控队列中是否有数据。
在点对点的消息系统中，消息保留在队列中，一个或多个消费者可以同时工作，但最终只有一个消费者可以消费消息。典型实例如订单处理系统，多个订单处理器可以同时工作，但对于一个特定的订单，只有其中一个订单处理器可以拿到并进行处理。

发布/订阅模型

基于推送的消息传送模型，由MQ主动推送消息给所有订阅者，即使某个订阅者不可用。
在发布-订阅系统中，消息被保留在主题中。消费者可以订阅一个或多个主题并使用主题中的所有消息。在发布-订阅系统中，消息生产者称为发布者，消息消费者称为订阅者。

kafka优点

解耦：解耦业务处理过程，两端业务流程仅通过消息API通信，两端程序可独立升级。
冗余：消息默认进行持久化，直到消息被完全处理，规避数据丢失风险。
扩展性：kafka支持动态扩容，缓解集群压力。
可恢复性：系统的一部分组件失效时，不会影响到整个系统。消息队列降低了进程间的耦合度，即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。
顺序保证：Kafka保证一个Partition内的消息的有序性。
缓冲：消息队列通过一个缓冲层来帮助任务最高效率的执行，写入队列的处理会尽可能的快速。缓冲有助于控制和优化数据流经过系统的速度。
异步通信：消息队列提供了异步处理机制，允许用户把消息放入队列，但并不立即处理，在需要时再处理。

kafka架构

架构图

在这里插入图片描述

主要构成

Record

Record即Kafka消息，是Kafka处理的主要对象。

Topic

Topic是承载Kafka消息数据的逻辑容器，用于区分具体的业务，但在物理上，不同Topic的消息分开存储，逻辑上一个Topic的消息虽然保存在一个或多个Broker上，但用户只需指定消息的Topic即可生产或消费数据而不必关心数据存储在何处。

partition

Topic被分割为一个或多个Partition，Partition是一个物理概念，对应一个或若干个目录。Partition内部的消息是有序的，Partition间的消息是无序的。
Kafka Broker配置文件中的num.partitions参数用于指定Topic的Partition数量，在创建Topic时也可以通过partitions参数指定Partition数量。

Broker

Kafka集群包含一个或多个服务器，每个服务器节点称为一个Broker。
Broker存储Topic的数据。如果某Topic有N个Partition，集群有N个Broker，那么每个Broker存储该Topic的一个Partition。
如果某Topic有N个Partition，集群有(N+M)个Broker，那么其中有N个Broker各存储Topic的一个Partition，剩下的M个Broker不存储Topic的Partition数据。
如果某Topic有N个Partition，集群中Broker数目少于N个，那么每个Broker存储Topic的一个或多个Partition。实际生产环境中应尽量避免，否则容易导致Kafka集群数据不均衡。

producer

Producer（生产者）是消息的发布者，生产者负责选择将消息数据分配给Topic中的某个分区，即生产者生产的每一条消息，会被写入到某一个Partition。

Consumer

Consumer（消费者）从Broker中消费消息，一个Consumer可以消费多个Topic的消息，也可以消费同一个Topic中的多个Partition中的消息，Partition允许多个Consumer同时消费，以提高Kafka Broker的吞吐量。

Consumer Group

Consumer Group是Kafka提供的可扩展且具有容错性的消费者机制，多个消费者实例共同组成的一个组，同时消费多个分区以实现高吞吐。Consumer Group内可以有多个消费者，共享一个公共的ID，即Group ID，Consumer Group内的所有消费者协调在一起来消费订阅Topic的所有分区。
Kafka保证同一个Consumer Group中只有一个Consumer会消费某条消息，Kafka保证的是稳定状态下每一个Consumer 实例只会消费某一个或多个特定的Partition，而某个Partition的数据只会被某一个特定的Consumer实例所消费。
如上图，两台Broker组成的Kafka群集，包含四个属于两个Consumer Group的分区（P0-P3）。Consumer Group A有两个消费者实例，Consumer Group B有四个消费者实例。

partition Replica

Replica（分区副本）为了防止消息丢失而创建的分区备份。Kafka中同一条消息能够被拷贝到多个地方以提供数据冗余。副本分为领导者副本和追随者副本，各自有不同的角色划分。副本是在分区层级下的，即每个分区可配置多个副本实现高可用。

Partition Leader

每个Partition有多个副本，其中有且仅有一个作为Leader，Leader是当前负责消息读写的Partition，所有读写操作只能发生于Leader分区上。

Partition Follower

用于同步Leader和Replica消息，保持消息同步。Leader与Follower的关系是主备关系，而非主从。

Zookeeper

Apache Zookeeper是一个分布式配置和同步服务，是Kafka的一个核心依赖，它是Broker和Consumer之间的协调接口。Broker在Zookeeper中存储基本元数据，通过Zookeeper集群共享信息，例如主题、代理、消费者偏移(队列读取器)等的信息。Zookeeper负责维护和协调Broker以及Broker Controller的选举。
Kafka 0.9版本前，offset（消息位移）由Zookeeper负责管理。

kafka Controller

Controller是Apache Kafka的核心组件，用于在Apache ZooKeeper的帮助下管理和协调整个Kafka集群，集群中任意一台Broker都能充当Controller的角色，JMX指标实时监控Controller存活状态。Controller管理整个集群中Partition和Replicas的状态，负责Leader的选举。
只有Broker Controller会向Zookeeper中注册Watcher，其他Broker及分区无需注册，即Zookeeper仅需监听Broker Controller的状态变化即可。

Kafka Controller选举

Broker启动时，尝试去ZooKeeper中创建controller节点。Kafka选举Controller的规则是：第一个成功创建controller节点的Broker会被指定为Controller。

Kafka Controller职责

topic主题管理（创建、删除、增加分区）。主题管理是指Controller帮助完成对Kafka主题的创建、删除以及分区增加的操作。当执行kafka-topics脚本时，大部分的后台工作是由Controller完成的。
分区再分配。分区再分配是指kafka-reassign-partitions脚本提供的对已有主题分区进行细粒度的分配功能。
Preferred领导者选举。Preferred领导者选举主要是Kafka为避免部分Broker负载过重而提供的一种换Leader的方案。
集群成员管理（新增Broker、Broker主动关闭、Broker宕机），包括自动检测新增Broker、Broker主动关闭及被动宕机。自动检测是依赖于Watch功能和ZooKeeper临时节点组合实现的。Controller会利用Watch机制检查ZooKeeper的/brokers/ids节点下的子节点数量变更。当有新Broker启动后，会在/brokers下创建专属的znode节点。一旦创建完毕，ZooKeeper会通过Watch机制将消息通知推送给Controller，Controller就能自动地感知到变化，进而开启后续的新增Broker作业。侦测Broker存活性则是依赖于临时节点。每个Broker启动后，会在/brokers/ids下创建一个临时znode。当Broker宕机或主动关闭后，Broker与ZooKeeper的会话结束，znode会被自动删除。ZooKeeper 的Watch机制将变更推送给Controller，Controller就能知道有Broker关闭或宕机，从而进行善后处理。
数据服务。Controller上保存了最全的集群元数据信息，其它所有 Broker会定期接收Controller发来的元数据更新请求，从而更新其内存中的缓存数据。

kafka Controller数据保存

所有topic主题信息，包括具体的分区信息，比如领导者副本是谁，ISR集合中有哪些副本等。
所有Broker信息，包括当前都有哪些运行中的Broker，哪些正在关闭中的Broker等。
所有涉及运维任务的分区，包括当前正在进行Preferred领导者选举以及分区再分配的分区列表。
Controller保存的数据在ZooKeeper中也保存一份，每当Controller初始化时，会从ZooKeeper上读取对应的元数据并填充到自己的缓存中。

kafka Controller故障转移

当Controller宕机时，ZooKeeper通过Watc机制感知到并删除/controller临时节点。然后，所有存活的Broker开始竞选新的Controller身份，BrokerN最终赢得选举，成功地在ZooKeeper上重建 /controller节点。BrokerN会从ZooKeeper中读取集群元数据信息，并初始化到自己的缓存中。

应用场景

存储系统

Kafka是一个非常好的存储系统，写入Kafka的数据将写入磁盘并进行复制以实现容错功能。Kafka允许生产者等待确认，以便直到完全复制并确保即使写入服务器失败的情况下写入也不会完成。
Kafka会认真对待存储并允许客户端控制其读取位置，因此可以将Kafka视为一种专用于高性能、低延迟，提供日志存储、复制和传播的专用分布式文件系统。

消息传递系统

消息传递具有排队和发布-订阅两种模型。
- 排队模型中，一组使用者可以从服务器中读取内容，并且每条记录都将转到其中一个。
  - 优点：允许将数据处理划分到多个使用者实例上，扩展处理能力。
  - 缺点：队列不是多用户的。
- 发布-订阅模型中，消息会广播给所有消费者
  - 优点：允许将数据广播到多个进程。
  - 缺点：每条消息都传递给每个订阅者，因此无法扩展处理。
Kafka的Consumer Group融合了排队模型和发布订阅模型的优点，Consumer Group允许将处理划分为一组进程（Consumer Group的成员），Kafka允许将消息广播到多个Consumer Group。
传统队列将消息按顺序保留在服务器上，如果多个消费者从队列中消费，则服务器将按记录的存储顺序分发记录。尽管服务器按顺序分发消息，但消息是异步传递给消费者的，因此消息可能在不同的消费者上乱序到达，即在并行使用的情况下消息会乱序。
Kafka在Topic内具有并行性（即Partition），通过将Topic中的Partition分配给Consumer Group中的消费者，每个分区都由Consumer Group中的一个消费者完全消费，Kafka能够在用户进程池中提供排序保证和负载均衡。Consumer Group中的消费者实例数量不能超过分区数量。

流处理

流处理器是指从数据源获取连续数据流，对输入进行一些处理并生成连续数据流以输出指定业务的任何东西。
Kafka提供了完全集成的Streams API，允许构建执行非重要处理的应用程序，流处理API建立在Kafka提供的核心原语上，使用生产者和使用者API进行输入，使用Kafka进行状态存储，并使用相同的组机制来实现流处理器实例之间的容错。
轻量级可使用，核心重要处理不建议使用。

总结

流处理是大数据未来趋势，网络发达个人数据剧增的当下，实时加载算法分析处理用户数据，如广告精确推送、影视推荐、个人画像、异常访问分析等，都有很大需要，数据的核心价值是信息，而实时计算能加强这种价值。
学海无涯，任重道远，加油。

羽落风起

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
2
评论
kafka（一）：介绍和架构、应用场景和同类型比对

文章目录说明kafka简介什么是kafkakafka高吞吐率实现kafka消息传递模式点对点模型发布/订阅模型kafka优点kafka架构架构图主要构成RecordTOPICpartitionBrokerproducerConsumerConsumer Grouppartition ReplicaPartition LeaderPartition FollowerZookeeper应用场景存储系统消息传递系统流处理同类型比对FlumeRabbitMQRedisZeroMQActiveMQRocketMQ总结
复制链接

扫一扫