Kafka（一）-- 概念及使用场景

Apache Kafka是 一个分布式流处理平台

流处理平台特性

  • 可以让你发布和订阅流式的记录。这一方面与消息队列或者企业消息系统类似。

  • 可以储存流式的记录，并且有较好的容错性。

  • 可以在流式记录产生时就进行处理。

Kafka组件

  • Topic和 Logs

    Kafka 通过 topic 对存储的流数据进行分类

    Topic 就是数据主题，是数据记录发布的地方，可以用来区分业务系统。Kafka 中的 Topics 总是多订阅者模式，一个 topic 可以拥有一个或者多个消费者来订阅它的数据

    对于每一个topic， Kafka集群都会维持一个分区日志，如图所示

  • Partition

  • Distribution

    Log 的分区被分布到集群中的多个服务器上，每个服务器处理它分到的分区， 根据配置每个分区还可以复制到其它服务器作为备份容错。

    每个分区有一个 leader，零或多个 follower。Leader 处理此分区的所有的读写请求，而 follower 被动的复制数据。如果 leader 宕机，其它的一个 follower 会被推举为新的 leader。 一台服务器可能同时是一个分区的 leader，另一个分区的 follower。 这样可以平衡负载，避免所有的请求都只让一台或者某几台服务器处理。

  • Producers

    生产者往某个Topic上发布消息，生产者也负责选择发布到Topic上的哪一个分区。最简单的方式从分区列表中轮流选择，也可以根据某种算法依照权重选择分区。开发者负责如何选择分区的算法。

  • Consumers
    消费者使用一个消费组名称来进行标识，发布到 topic 中的每条记录被分配给订阅消费组中的一个消费者实例。消费者实例可以分布在多个进程中或者多个机器上。

    • 如果所有的消费者实例在同一消费组中，消息记录会负载平衡到每一个消费者实例。
    • 如果所有的消费者实例在不同的消费组中，每条消息记录会广播到所有的消费者进程。

  • Replication

    每个partition还会被复制到其它服务器作为replication，这是一种冗余备份策略

    • 同一个partition的多个replication不允许在同一broker上
    • 每个partition的replication中，有一个leader ，零或多个follower
    • leader处理此分区的所有的读写请求， follower仅仅被动的复制数据
    • leader宕机后，会从follower中选举出新的leader

四个核心 API

  • Producer API

允许一个应用程序发布一串流式的数据到一个或者多个 Kafka topic。

Properties props = new Properties();
props.put("batch.size",16384);   //默认值为16384
props.put("linger.ms",16384);   //默认值为0
props.put("acks", "all");
props.put("retries",1);
//...
Producer<String, String> producer = new KafkaProducer(props);
ProducerRecord<String, String> record = new ProducerRecord<String, String>("my-topic", "key", "value");
producer.send(record);
producer.close();

Producer会为每个partition维护一个缓冲，用来记录还没有发送的数据，每个缓冲区大小用batch.size指定，默认值为16k.

linger.ms为，buffer中的数据在达到batch.size前，需要等待的时间

acks用来配置请求成功的标准

  • Consumer API

    • Kafka Simple Consumer

      Simple Cnsumer 位于kafka.javaapi.consumer包中，不提供负载均衡、容错的特性每次获取数据都要指定topic、partition、offset、fetchSize

    • High-level Consumer

      该客户端透明地处理kafka broker异常，透明地切换consumer的partition，通过和broker交互来实现consumer group级别的负载均衡。

允许一个应用程序订阅一个或多个 topic ，并且对发布给他们的流式数据进行处理。

  • Streams API

允许一个应用程序作为一个流处理器，消费一个或者多个 topic 产生的输入流，然后生产一个输出流到一个或多个 topic 中去，在输入输出流中进行有效的转换。

  • Connector API

允许构建并运行可重用的生产者或者消费者，将Kafka topics连接到已存在的应用程序或者数据系统。比如，连接到一个关系型数据库，捕捉表（table）的所有变更内容

Kafka通信

在Kafka中，客户端和服务器之间的通信是通过简单，高性能，语言无关的TCP协议完成的。此协议已版本化并保持与旧版本的向后兼容性。Kafka提供多种语言客户端。

kafka整体架构

适合场景

  • 构造实时流数据管道，它可以在系统或应用之间可靠地获取数据。 (相当于消息队列)

  • 构建实时流式应用程序，对这些流数据进行转换或者影响。

消息

kafka 更好的替换传统的消息系统，消息系统被用于各种场景（解耦数据生产者，缓存未处理的消息），与大多数消息系统比较，kafka 有更好的吞吐量，内置分区，副本和故障转移等功能，这有利于处理大规模的消息。

根据官方的经验，通常消息传递使用较低的吞吐量，但可能要求较低的端到端延迟，kafka 提供强大的持久性来满足这一要求。在这方面，Kafka 可以与传统的消息传递系统（ActiveMQ 和 RabbitMQ）相媲美。

跟踪网站活动

kafka 的最初始作用就是是将用户活动跟踪管道重建为一组实时发布-订阅源。 把网站活动（浏览网页、搜索或其他的用户操作）发布到中心 topic，其中每个活动类型有一个 topic。 这些订阅源提供一系列用例，包括实时处理、实时监视、对加载到Hadoop或离线数据仓库系统的数据进行离线处理和报告等。

每个用户浏览网页时都生成了许多活动信息，因此活动跟踪的数据量通常非常大。这就非常使用使用 kafka。

日志聚合

日志聚合系统通常从服务器收集物理日志文件，并将其置于一个中心系统（可能是文件服务器或HDFS）进行处理。

kafka 从这些日志文件中提取信息，并将其抽象为一个更加清晰的消息流。 这样可以实现更低的延迟处理且易于支持多个数据源及分布式数据的消耗。

与 Scribe 或 Flume 等以日志为中心的系统相比，Kafka具备同样出色的性能、更强的耐用性（因为复制功能）和更低的端到端延迟。

流处理

从0.10.0.0开始，kafka 支持轻量，但功能强大的流处理。

kafka消息处理包含多个阶段。其中原始输入数据是从kafka主题消费的，然后汇总，丰富，或者以其他的方式处理转化为新主题以供进一步消费或后续处理。

例如，一个推荐新闻文章，文章内容可能从“articles”主题获取；然后进一步处理内容，得到一个处理后的新内容，最后推荐给用户。这种处理是基于单个主题的实时数据流。

除了Kafka Streams，还有 Apache Storm 和 Apache Samza 也是不错的流处理框架。

事件采集

Event sourcing是一种应用程序设计风格，按时间来记录状态的更改。 Kafka 可以存储非常多的日志数据，为基于 event sourcing 的应用程序提供强有力的支持。

提交日志

kafka 可以从外部为分布式系统提供日志提交功能。 日志有助于记录节点和行为间的数据，采用重新同步机制可以从失败节点恢复数据。 Kafka的日志压缩 功能支持这一用法。 这一点与Apache BookKeeper 项目类似。

posted @ 2022-08-07 23:05  snail灬  阅读(167)  评论(0)  编辑  收藏  举报