Kafka介绍之一

匿名 (未验证) 提交于 2019-12-02 23:05:13

Apache Kafka是一个分布式消息发布订阅系统。它最初由LinkedIn公司基于独特的设计实现为一个分布式的提交日志系统( a distributed commit log),,之后成为Apache项目的一部分。Kafka系统快速、可扩展并且可持久化。它的分区特性,可复制和可容错都是其不错的特性。

  1. Kafka特性

Apache Kafka与传统消息系统相比,有以下不同:

  • 它被设计为一个分布式系统,易于向外扩展;
  • 它同时为发布和订阅提供高吞吐量;
  • 它支持多订阅者,当失败时能自动平衡消费者;
  • 它将消息持久化到磁盘,因此可用于批量消费,例如ETL,以及实时应用程序。
  1. 结构与基本概念
  • topics: kafka通过topics维护各类信息。
  • producer:发布消息到Kafka topic的进程。
  • consumer:订阅kafka topic进程和处理订阅的消息的进程。
  • broker:kafka集群的每个server叫broker.提供了语言无关、高性能、简单的client-server的链接方式。
    1. Topics and Logs
  • topic是发送消息的类别名称。每个partition是持续添加的有序的不可变的消息序列-commit log. partition内部的消息分配唯一的Id number--offset.
  • 无论是否消费,kafka在一段可配置时间内会保留所有提交的消息。如设置2天,发布后两天内都可以消费,两天后就会腾出空间。kafka的性能是恒定量,多保留些数据不是问题。
  • 这些组合,造成kafka consumer非常轻量级,基本上不会对其他consumer造成影响。(如我们可以用命令行tail等操作 察看内容,不会改变已经存在的consumer的消费行为).

这些特性好处:允许日志量超出单台服务器,每个独立分区必须适应拥有它的server,一个topic可以有多个partition(持有任意数量的数据);他们作为并行单元执行。

    1. Distribution(分布式)
  • 日志分区分布在Kafka集群上,每个server处理一部分分区的数据和请求,每个partition都可以有一个配置大小的容错server.
    1. producers

producer负责选择哪个消息给topic中的哪个partition。这可以用轮询的方式简单的balance load,或者基于语义partition function(如根据消息Key).

    1. consumers
  • 消息传统两种使用模式:队列和发布-订阅。 队列模式下,几个消费者可以从服务器读取,消息只会到一个消费者;发布订阅--消息会广博到所有消费者。
  • 消费者给自己一个consumer group 名称,发布给topic每个消息传递到每个consumer订阅组中的一个实例中。consumer progress可以独立线程或者独立机器。

如果所有的consumer instance都有相同的consumer group, 类似于传统的queue,负载到consumers.

如果所有的consumer instance都有不同的consumer group, 类似于发布-订阅,广播到所有的consumers.

更常见的是有多个consumer group,每个逻辑订阅组一个名字。每个组为了扩展性和容错性由多个consumer instance组成。这超出了发布订阅模式语义,每个订阅者是consumer群,不是单个进程。

  • kafka比常见的消息系统有更强的排序保证。

传统队列系统,并行consumer会让本来有序的队列,处理完的速度并不相同。kafka可以保证顺序。通过分配partition给consumer group中的consumer保证每个分区由consumer中的一个consumer消费。(这样保证consumer是partiton的唯一reader,按序消费数据,因为分区多,还是能平衡负载.这不能有比分区更多的partition.)

当然Kafka只提供了分区内部的有序性,不能跨partition. 每个分区的有序性,结合按Key分partition的能力对大多应用都够用了。全序---one topic-one partition-one consumer,失去了并行。

    1. Guarantees
  • partition会按照publish message的顺序排放消息。
  • consumer看到消息的顺序与在Log存储的顺序相同。
  • 对于复制因子N,容忍N-1 server宕机不影响服务。
  1. 使用场景
  • messaging消息队列

可以用来替换传统消息代理(解耦生产者消费者,缓存未处理消息),kafka与以往的软件比更大的吞吐量、内置的分区和分区复制机制、容错机制。更适合做大型消息处理的解决方案。

根据经验消息系统经常需要吞吐量不高,但是需要端到端低延迟、经常以来Kafka提供的持久化保证。(与activemq和rabbitmq对比).

  • website activity tracking 网站活动跟踪

kafka的原始用途:通过重建用户跟踪管道为一组实时的发布-订阅feeds。这意味着网站活动(pv,search,用户的其他活动)根据类型被发布到中心topics的一个topic. 这些feed广泛用于大量用例的订阅包括实时处理、实时监控、load to hadoop或者离线数据仓库为离线处理和报告。

活动跟踪需要高吞吐量,许多活动消息由每个用户pv生成。

  • Metrics 度量

kafka经常用于运营监测数据;包括聚合统计信息从分布式应用来生成运营数据中心化。

  • log aggregation日至聚合

分散文件放入集中位置(file server/hdfs)处理。kafka做日志聚集的替代。kafka抽出文件内容,给日志和事件数据一个清洁提取做为消息流。这允许低延迟处理和易于支持多个数据源和多个消费者消费。对比中心化聚合系统scribe/flume,kafka提供更好的性能,更强的持久化保证,由于replication,更低的端到端延迟。

  • stream processing流处理

许多用户做阶段性的数据处理(数据消耗原始数据,然后聚合、补充、或者重新转换为Kafka topic进一步处理)。

例如:文章推荐的一个处理流可能从rss抓取文章内容 然后发布到article topic;进一步处理可能规范化或者重复数据删除生成一个清洗过的article content;最后阶段可能试图匹配这个内容给用户。这从个人topic创建了实时数据流图;storm和Samza是实现这类转换的工具。

  • event sourcing 事件溯源

事件溯源是一种设计模式,状态改变被记录为一系列记录。Kafka支持大量的日志数据,非常适合做这种类型数据的后端。

  • Commit Log

kafka可以做为一种分布式系统外部commit-log工具。日志帮助复制节点间的数据,为失败节点重新存储数据的重同步机制。日志压缩功能帮助支持这种用途,类似于apache bookkeeper项目。

文章来源: https://blog.csdn.net/yueguanglanying1/article/details/86569173
易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!