宁波高端网站设计厂家,建设网站要多久的时间,北京十大科技公司,高清免费爱做网站目录
一. 前言
二. 使用场景
三. 分布式的流平台
四. Kafka 的基本术语
4.1. 主题和日志 #xff08;Topic 和 Log#xff09;
4.2. 分布式#xff08;Distribution#xff09;
4.3. 异地数据同步技术#xff08;Geo-Replication#xff09;
4.4. 生产者#xf…目录
一. 前言
二. 使用场景
三. 分布式的流平台
四. Kafka 的基本术语
4.1. 主题和日志 Topic 和 Log
4.2. 分布式Distribution
4.3. 异地数据同步技术Geo-Replication
4.4. 生产者Producers
4.5. 消费者Consumers
4.6. Kafka 的保证Guarantees
4.7. Kafka 作为一个消息系统
4.8. Kafka 作为一个存储系统
4.9. Kafka 的流处理
五. 总结 一. 前言 Kafka 最初由 Linkedin 公司开发是一个分布式、支持分区的Partition、多副本的Replica基于 Zookeeper 协调的分布式消息系统它的最大的特性就是可以实时的处理大量数据以满足各种需求场景比如基于 Hadoop 的批处理系统、低延迟的实时系统、Storm/Spark 流式处理引擎web/nginx 日志、访问日志消息服务等等用 scala 语言编写Linkedin 于2010年贡献给了 Apache 基金会并成为顶级开源项目。 Kafka 实际上算作是分布式的流处理平台具备消息中间件的功能在大数据领域作为流计算的平台也会做消息分发。 Kafka 具有高吞吐量、高横向扩容以及故障转移支持幂等性、事务以及三种消息语义并且具有消息持久化等特点。
二. 使用场景 下面是一些关于 Apache Kafka 非常流行的使用场景。这些领域的概述可查看英文博客《The Log: What every software engineer should...》。
1. 消息系统Kafka 可以更好的替换传统的消息系统消息系统被用于各种场景解耦数据生产者缓存未处理的消息等与大多数消息系统比较Kafka 有更好的吞吐量内置分区、副本和故障转移这有利于处理大规模的消息。 根据我们的经验消息往往用于较低的吞吐量但需要低的端到端延迟并需要提供强大的耐用性的保证。在这一领域的 Kafka 比得上传统的消息系统如 ActiveMQ 或 RabbitMQ。
2. 行为追踪Kafka 经常被用来记录 Web 用户或者 App 用户的各种活动如浏览网页、搜索、点击等活动这些活动信息被各个服务器发布到 Kafka 的 Topic 中然后订阅者通过订阅这些 Topic来做实时的监控分析或者装载到 Hadoop、数据仓库中做离线分析和挖掘。
3. 运营指标Kafka 也经常用来记录运营监控数据。包括收集各种分布式应用的数据生产各种操作的集中反馈比如报警和报告。
4. 日志收集许多人使用 Kafka 作为日志聚合解决方案的替代品。日志聚合通常从服务器中收集物理日志文件并将它们放在中央位置可能是文件服务器或 HDFS进行处理。Kafka 抽象出文件的细节并将日志或事件数据更清晰地抽象为消息流。这允许更低延迟的处理并更容易支持多个数据源和分布式数据消费。
5. 流处理Kafka 中的消息处理一般包含多个阶段。其中原始输入数据是从 Kafka 主题消费的然后汇总丰富或者以其他的方式处理转化为新主题。除了 Kafka Streams还有 Apache Storm和 Apache Samza 可选择。 例如一个推荐新闻文章文章内容可能从 articles 主题获取然后进一步处理内容得到一个处理后的新内容最后推荐给用户。这种处理是基于单个主题的实时数据流。从 0.10.0.0 开始轻量但功能强大的流处理就可以这样进行数据处理了。
6. 事件采集事件采集是一种应用程序的设计风格其中状态的变化根据时间的顺序记录下来Kafka 支持这种非常大的存储日志数据的场景。
三. 分布式的流平台
Kafka 作为一个分布式的流平台意味着必须具有三个关键能力
发布和订阅消息流在这方面它类似于一个消息队列。以容错故障转移的方式存储消息流。在消息流发生时处理它们。
Kafka 主要应用于2大类应用
构建实时的流数据管道可靠地获取系统和应用程序之间的数据。构建实时流的应用程序对数据流进行转换或反应。
Kafka 的几个概念
Kafka 作为一个集群运行在一个或多个服务器上。Kafka 集群存储的消息是以 Topic 为类别记录的。每个消息也叫记录 Record是由一个 key一个 value 和时间戳构成。
Kafka 有四个核心 API
应用程序使用 Producer API 发布消息到一个或多个 Topic主题中。应用程序使用 Consumer API 来订阅一个或多个 Topic并处理产生的消息。应用程序使用 Streams API 充当一个流处理器从一个或多个 Topic 消费输入流并生产一个输出流到一个或多个输出 Topic有效地将输入流转换到输出流。Connector API 可构建或运行可重用的生产者或消费者将 Topic 连接到现有的应用程序或数据系统。例如连接到关系数据库的连接器可以捕获表的每个变更。 Client 和 Server 之间的通讯是通过一条简单、高性能并且和开发语言无关的 TCP 协议。并且该协议保持与老版本的兼容。Kafka 提供了Java Client客户端。除了Java 客户端外还有非常多的其它编程语言的客户端。
四. Kafka 的基本术语
先通过一张图我们来捋一捋相关的概念及之间的关系 1. Producer发布消息的对象称之为主题生产者Kafka topic producer。
2. Consumer订阅消息并处理发布的消息的对象称之为主题消费者Consumers。
3. TopicKafka 将消息分门别类每一类的消息称之为一个主题Topic。
4. PartitionTopic 的分区每个 Topic 可以有多个分区分区的作用是做负载提高 Kafka 的吞吐量。同一个 Topic 在不同的分区的数据是不重复的Partition 的表现形式就是一个一个的文件夹。
5. Replication每一个分区都有多个副本副本的作用是做备胎。当主分区Leader故障的时候会选择一个备胎Follower上位成为 Leader。在 Kafka 中默认副本的最大数量是10个且副本的数量不能大于 Broker 的数量follower 和 leader 绝对是在不同的机器同一机器对同一个分区也只可能存放一个副本包括自己。
6. Message每一条发送的消息主体。
7. Consumer Group我们可以将多个消费者组成一个消费者组在 Kafka 的设计中同一个分区的数据只能被消费者组中的某一个消费者消费。同一个消费者组的消费者可以消费同一个 Topic 的不同分区的数据这也是为了提高 Kafka 的吞吐量。
8. Broker已发布的消息保存在一组服务器中称之为 Kafka 集群。集群中的每一个节点服务器都是一个代理Broker。 消费者可以订阅一个或多个主题Topic并从 Broker 拉数据从而消费这些已发布的消息。
4.1. 主题和日志 Topic 和 Log Topic 是发布的消息的类别名一个 Topic 可以有零个一个或多个消费者订阅该主题的消息。对于每个 TopicKafka 集群都会维护一个分区 Log就像下图中所示 每一个分区都是一个顺序的、不可变的消息队列并且可以持续的添加。分区中的消息都被分了一个序列号称之为偏移量offset在每个分区中此偏移量都是唯一的。 Kafka 集群保持所有的消息直到它们过期无论消息是否被消费。实际上消费者所持有的仅有的元数据就是这个 offset偏移量也就是说 offset 由消费者来控制正常情况下当消费者消费消息的时候偏移量也线性的的增加。但是实际偏移量由消费者控制消费者可以将偏移量重置为更早的位置重新读取消息。可以看到这种设计对消费者来说操作自如一个消费者的操作不会影响其它消费者对此 Log 的处理。 再说说分区。Kafka 中采用分区的设计有几个目的
一是可以处理更多的消息不受单台服务器的限制。Topic 拥有多个分区意味着它可以不受限的处理更多的数据。第二分区可以作为并行处理的单元稍后会谈到这一点。
4.2. 分布式Distribution Log 的分区被分布到集群中的多个服务器上。每个服务器处理它分到的分区。 根据配置每个分区还可以复制到其它服务器作为备份容错。 每个分区有一个 leader零或多个 follower。Leader处理此分区的所有的读写请求而 follower 被动的复制数据。如果 leader 宕机其它的一个follower 会被推举为新的 leader。一台服务器可能同时是一个分区的 leader另一个分区的follower。这样可以平衡负载避免所有的请求都只让一台或者某几台服务器处理。
4.3. 异地数据同步技术Geo-Replication Kafka MirrorMaker 为群集提供 geo-replication 支持。借助 MirrorMaker消息可以跨多个数据中心或云区域进行复制。 您可以在 active/passive 场景中用于备份和恢复或者在 active/passive方案中将数据置于更接近用户的位置或数据本地化。
4.4. 生产者Producers 生产者往某个 Topic 上发布消息。生产者也负责选择发布到 Topic 上的哪一个分区。最简单的方式是从分区列表中轮流选择。也可以根据某种算法依照权重选择分区。生产者负责如何选择分区的算法。
4.5. 消费者Consumers 通常来讲消息模型可以分为两种 队列Queue和发布-订阅式Pub/Sub。 队列的处理方式是一组消费者从服务器读取消息一条消息只有其中的一个消费者来处理。在发布-订阅模型中消息被广播给所有的消费者接收到消息的消费者都可以处理此消息。 Kafka 为这两种模型提供了单一的消费者抽象模型 消费者组Consumer Group。消费者用一个消费者组名标记自己。 一个发布在 Topic 上消息被分发给此消费者组中的一个消费者。假如所有的消费者都在一个组中那么这就变成了 Queue 模型。假如所有的消费者都在不同的组中那么就完全变成了发布-订阅模型。更通用的我们可以创建一些消费者组作为逻辑上的订阅者。每个组包含数目不等的消费者一个组内多个消费者可以用来扩展性能和容错。正如下图所示 2个Kafka节点托管4个分区P0-P32个消费者组消费组A有2个消费者实例消费组B有4个。 正如传统的消息系统一样Kafka 保证消息的顺序不变。传统的队列模型保持消息并且保证它们的先后顺序不变。但是尽管服务器保证了消息的顺序消息还是异步的发送给各个消费者消费者收到消息的先后顺序不能保证了。这也意味着并行消费将不能保证消息的先后顺序。 用过传统的消息系统的同学肯定清楚消息的顺序处理很让人头痛。如果只让一个消费者处理消息又违背了并行处理的初衷。在这一点上 Kafka 做的更好尽管并没有完全解决上述问题。Kafka 采用了一种分而治之的策略分区。 因为 Topic 分区中消息只能由消费者组中的唯一一个消费者处理所以消息肯定是按照先后顺序进行处理的。但是它也仅仅是保证 Topic 的一个分区顺序处理不能保证跨分区的消息先后处理顺序。所以如果你想要顺序的处理 Topic 的所有消息那就只提供一个分区。
4.6. Kafka 的保证Guarantees
1. 生产者发送到一个特定的 Topic 的分区上消息将会按照它们发送的顺序依次加入也就是说如果一个消息 M1 和 M2 使用相同的 Producer 发送M1 先发送那么 M1 将比 M2 的 offset 低并且优先的出现在日志中。
2. 消费者收到的消息也是此顺序。
3. 如果一个 Topic 配置了复制因子Replication Factor为 N 那么可以允许 N-1 服务器宕机而不丢失任何已经提交committed的消息。
有关这些保证的更多详细信息请关注后续文章。
4.7. Kafka 作为一个消息系统
Kafka的流与传统企业消息系统相比 传统的消息有两种模式队列和发布订阅。 在队列模式中消费者池从服务器读取消息每个消息只被其中一个读取; 发布订阅模式消息广播给所有的消费者。这两种模式都有优缺点队列的优点是允许多个消费者瓜分处理数据这样可以扩展处理。但是队列不像多个订阅者一旦消息者进程读取后故障了那么消息就丢了。而发布和订阅允许你广播数据到多个消费者由于每个订阅者都订阅了消息所以没办法缩放处理。
Kafka 中消费者组有两个概念
队列消费者组Consumer Group允许同名的消费者组成员瓜分处理。发布订阅允许你广播消息给多个消费者组不同名。
Kafka 的每个 Topic 都具有这两种模式。
Kafka 有比传统的消息系统更强的顺序保证 传统的消息系统按顺序保存数据如果多个消费者从队列消费则服务器按存储的顺序发送消息。尽管服务器按顺序发送但是消息会异步传递到消费者因此消息可能乱序到达消费者。这意味着消息存在并行消费的情况顺序就无法保证。消息系统常常通过仅设1个消费者来解决这个问题但是这意味着没用到并行处理。 Kafka 做得更好。通过并行 Topic 的 Partition —— Kafka 提供了顺序保证和负载均衡。每个Partition 仅由同一个消费者组中的一个消费者消费到。并确保消费者是该 Partition 的唯一消费者并按顺序消费数据。每个 Topic 有多个分区则需要对多个消费者做负载均衡但请注意相同的消费者组中不能有比分区更多的消费者否则多出的消费者一直处于空等待不会收到消息。
4.8. Kafka 作为一个存储系统 所有发布消息到消息队列和消费分离的系统实际上都充当了一个存储系统发布的消息先存储起来。Kafka 比别的系统的优势是它是一个非常高性能的存储系统。 写入到 Kafka 的数据将写到磁盘并复制到集群中保证容错性。并允许生产者等待消息应答直到消息完全写入。 Kafka 的磁盘结构无论你服务器上有50KB 或50TB执行是相同的。 Client 来控制读取数据的位置。你还可以认为 Kafka 是一种专用于高性能、低延迟、提交日志存储、复制和传播特殊用途的分布式文件系统。
4.9. Kafka 的流处理 仅仅读、写和存储是不够的Kafka 的目标是实时的流处理。在 Kafka 中流处理持续获取输入Topic 的数据进行处理加工然后写入输出 Topic。 例如一个零售 APP接收销售和出货的输入流统计数量或调整价格后输出。可以直接使用Producer API 和 Consumer API 进行简单的处理。对于复杂的转换Kafka 提供了更强大的Streams API。可构建聚合计算或连接流到一起的复杂应用程序。 助于解决此类应用面临的硬性问题处理无序的数据代码更改的再处理执行状态计算等。 Streams API 在 Kafka 中的核心使用 Producer API 和 Consumer API 作为输入利用 Kafka做状态存储使用相同的组机制在 Stream 处理器实例之间进行容错保障。
五. 总结 消息传递、存储和流处理的组合看似反常但对于 Kafka 作为流式处理平台的作用至关重要。
1. 像 HDFS 这样的分布式文件系统允许存储静态文件来进行批处理。这样系统可以有效地存储和处理来自过去的历史数据。
2. 传统企业的消息系统允许在你订阅之后处理未来的消息在未来数据到达时处理它。
Kafka 结合了这两种能力这种组合对于 Kafka 作为流处理应用和流数据管道平台是至关重要的。 批处理以及消息驱动应用程序的流处理的概念通过组合存储和低延迟订阅流处理应用可以用相同的方式对待过去和未来的数据。它是一个单一的应用程序它可以处理历史的存储数据当它处理到最后一个消息时它进入等待未来的数据到达而不是结束。 同样对于流数据管道pipeline订阅实时事件的组合使得可以将 Kafka 用于非常低延迟的管道。但是可靠地存储数据的能力使得它可以将其用于必须保证传递的关键数据或与仅定期加载数据或长时间维护的离线系统集成在一起。流处理可以在数据到达时转换它。
