长沙正规关键词优化价格从优,关系网站优化公司,深圳建网站制作维护,我要看一集片做网站Kafka作为一个分布式的流平台#xff0c;这到底意味着什么#xff1f; 我们认为#xff0c;一个流处理平台具有三个关键能力#xff1a; 发布和订阅消息#xff08;流#xff09;#xff0c;在这方面#xff0c;它类似于一个消息队列或企业消息系统。 以容错的方式存储… Kafka作为一个分布式的流平台这到底意味着什么 我们认为一个流处理平台具有三个关键能力 发布和订阅消息流在这方面它类似于一个消息队列或企业消息系统。 以容错的方式存储消息流。 在消息流发生时处理它们。 什么是kakfa的优势 它应用于2大类应用 构建实时的流数据管道可靠地获取系统和应用程序之间的数据。 构建实时流的应用程序对数据流进行转换或反应。 要了解kafka是如何做这些事情的让我们从下到上深入探讨kafka的能力。 首先几个概念 kafka作为一个集群运行在一个或多个服务器上。 kafka集群存储的消息是以topic为类别记录的。 每个消息也叫记录record我习惯叫消息是由一个key一个value和时间戳构成。 kafka有四个核心API 应用程序使用Producer API发布消息到1个或多个topic主题。 应用程序使用Consumer API来订阅一个或多个topic并处理产生的消息。 应用程序使用Streams API充当一个流处理器从1个或多个topic消费输入流并生产一个输出流到1个或多个输出topic有效地将输入流转换到输出流。 Connector API允许构建或运行可重复使用的生产者或消费者将topic连接到现有的应用程序或数据系统。例如一个关系数据库的连接器可捕获每一个变化。 Client和Server之间的通讯是通过一条简单、高性能并且和开发语言无关的TCP协议。除了Java Client外还有非常多的其它编程语言的Client。 首先来了解一下Kafka所使用的基本术语 Topic Kafka将消息种子(Feed)分门别类每一类的消息称之为一个主题(Topic). Producer 发布消息的对象称之为主题生产者(Kafka topic producer) Consumer 订阅消息并处理发布的消息的种子的对象称之为主题消费者(consumers) Broker 已发布的消息保存在一组服务器中称之为Kafka集群。集群中的每一个服务器都是一个代理(Broker). 消费者可以订阅一个或多个主题topic并从Broker拉数据从而消费这些已发布的消息。 话题和日志 (Topic和Log) 让我们更深入的了解Kafka中的Topic。 Topic是发布的消息的类别或者种子Feed名。对于每一个TopicKafka集群维护这一个分区的log就像下图中的示例 每一个分区都是一个顺序的、不可变的消息队列 并且可以持续的添加。分区中的消息都被分了一个序列号称之为偏移量(offset)在每个分区中此偏移量都是唯一的。 Kafka集群保持所有的消息直到它们过期 无论消息是否被消费了。 实际上消费者所持有的仅有的元数据就是这个偏移量也就是消费者在这个log中的位置。 这个偏移量由消费者控制正常情况当消费者消费消息的时候偏移量也线性的的增加。但是实际偏移量由消费者控制消费者可以将偏移量重置为更老的一个偏移量重新读取消息。 可以看到这种设计对消费者来说操作自如 一个消费者的操作不会影响其它消费者对此log的处理。 再说说分区。Kafka中采用分区的设计有几个目的。一是可以处理更多的消息不受单台服务器的限制。Topic拥有多个分区意味着它可以不受限的处理更多的数据。第二分区可以作为并行处理的单元稍后会谈到这一点。 分布式(Distribution) Log的分区被分布到集群中的多个服务器上。每个服务器处理它分到的分区。 根据配置每个分区还可以复制到其它服务器作为备份容错。 每个分区有一个leader零或多个follower。Leader处理此分区的所有的读写请求而follower被动的复制数据。如果leader宕机其它的一个follower会被推举为新的leader。 一台服务器可能同时是一个分区的leader另一个分区的follower。 这样可以平衡负载避免所有的请求都只让一台或者某几台服务器处理。 生产者(Producers) 生产者往某个Topic上发布消息。生产者也负责选择发布到Topic上的哪一个分区。最简单的方式从分区列表中轮流选择。也可以根据某种算法依照权重选择分区。开发者负责如何选择分区的算法。 消费者(Consumers) 通常来讲消息模型可以分为两种 队列和发布-订阅式。 队列的处理方式是 一组消费者从服务器读取消息一条消息只有其中的一个消费者来处理。在发布-订阅模型中消息被广播给所有的消费者接收到消息的消费者都可以处理此消息。Kafka为这两种模型提供了单一的消费者抽象模型 消费者组 consumer group。 消费者用一个消费者组名标记自己。 一个发布在Topic上消息被分发给此消费者组中的一个消费者。 假如所有的消费者都在一个组中那么这就变成了queue模型。 假如所有的消费者都在不同的组中那么就完全变成了发布-订阅模型。 更通用的 我们可以创建一些消费者组作为逻辑上的订阅者。每个组包含数目不等的消费者 一个组内多个消费者可以用来扩展性能和容错。正如下图所示 2个kafka集群托管4个分区P0-P32个消费者组消费组A有2个消费者实例消费组B有4个。 正像传统的消息系统一样Kafka保证消息的顺序不变。 再详细扯几句。传统的队列模型保持消息并且保证它们的先后顺序不变。但是 尽管服务器保证了消息的顺序消息还是异步的发送给各个消费者消费者收到消息的先后顺序不能保证了。这也意味着并行消费将不能保证消息的先后顺序。用过传统的消息系统的同学肯定清楚消息的顺序处理很让人头痛。如果只让一个消费者处理消息又违背了并行处理的初衷。 在这一点上Kafka做的更好尽管并没有完全解决上述问题。 Kafka采用了一种分而治之的策略分区。 因为Topic分区中消息只能由消费者组中的唯一一个消费者处理所以消息肯定是按照先后顺序进行处理的。但是它也仅仅是保证Topic的一个分区顺序处理不能保证跨分区的消息先后处理顺序。 所以如果你想要顺序的处理Topic的所有消息那就只提供一个分区。 Kafka的保证(Guarantees) 生产者发送到一个特定的Topic的分区上消息将会按照它们发送的顺序依次加入也就是说如果一个消息M1和M2使用相同的producer发送M1先发送那么M1将比M2的offset低并且优先的出现在日志中。 消费者收到的消息也是此顺序。 如果一个Topic配置了复制因子replication facto为N 那么可以允许N-1服务器宕机而不丢失任何已经提交committed的消息。 有关这些保证的更多详细信息请参见文档的设计部分。 kafka作为一个消息系统 Kafka的流与传统企业消息系统相比的概念如何 传统的消息有两种模式队列和发布订阅。 在队列模式中消费者池从服务器读取消息每个消息只被其中一个读取; 发布订阅模式消息广播给所有的消费者。这两种模式都有优缺点队列的优点是允许多个消费者瓜分处理数据这样可以扩展处理。但是队列不像多个订阅者一旦消息者进程读取后故障了那么消息就丢了。而发布和订阅允许你广播数据到多个消费者由于每个订阅者都订阅了消息所以没办法缩放处理。 kafka中消费者组有两个概念队列消费者组consumer group允许同名的消费者组成员瓜分处理。发布订阅允许你广播消息给多个消费者组不同名。 kafka的每个topic都具有这两种模式。 kafka有比传统的消息系统更强的顺序保证。 传统的消息系统按顺序保存数据如果多个消费者从队列消费则服务器按存储的顺序发送消息但是尽管服务器按顺序发送消息异步传递到消费者因此消息可能乱序到达消费者。这意味着消息存在并行消费的情况顺序就无法保证。消息系统常常通过仅设1个消费者来解决这个问题但是这意味着没用到并行处理。 kafka做的更好。通过并行topic的parition —— kafka提供了顺序保证和负载均衡。每个partition仅由同一个消费者组中的一个消费者消费到。并确保消费者是该partition的唯一消费者并按顺序消费数据。每个topic有多个分区则需要对多个消费者做负载均衡但请注意相同的消费者组中不能有比分区更多的消费者否则多出的消费者一直处于空等待不会收到消息。 kafka作为一个存储系统 所有发布消息到消息队列和消费分离的系统实际上都充当了一个存储系统发布的消息先存储起来。Kafka比别的系统的优势是它是一个非常高性能的存储系统。 写入到kafka的数据将写到磁盘并复制到集群中保证容错性。并允许生产者等待消息应答直到消息完全写入。 kafka的磁盘结构 - 无论你服务器上有50KB或50TB执行是相同的。 client来控制读取数据的位置。你还可以认为kafka是一种专用于高性能低延迟提交日志存储复制和传播特殊用途的分布式文件系统。 kafka的流处理 仅仅读写和存储是不够的kafka的目标是实时的流处理。 在kafka中流处理持续获取输入topic的数据进行处理加工然后写入输出topic。例如一个零售APP接收销售和出货的输入流统计数量或调整价格后输出。 可以直接使用producer和consumer API进行简单的处理。对于复杂的转换Kafka提供了更强大的Streams API。可构建聚合计算或连接流到一起的复杂应用程序。 助于解决此类应用面临的硬性问题处理无序的数据代码更改的再处理执行状态计算等。 Sterams API在Kafka中的核心使用producer和consumer API作为输入利用Kafka做状态存储使用相同的组机制在stream处理器实例之间进行容错保障。 拼在一起 消息传递存储和流处理的组合看似反常但对于Kafka作为流式处理平台的作用至关重要。 像HDFS这样的分布式文件系统允许存储静态文件来进行批处理。这样系统可以有效地存储和处理来自过去的历史数据。 传统企业的消息系统允许在你订阅之后处理未来的消息在未来数据到达时处理它。 Kafka结合了这两种能力这种组合对于kafka作为流处理应用和流数据管道平台是至关重要的。 批处理以及消息驱动应用程序的流处理的概念通过组合存储和低延迟订阅流处理应用可以用相同的方式对待过去和未来的数据。它是一个单一的应用程序它可以处理历史的存储数据当它处理到最后一个消息时它进入等待未来的数据到达而不是结束。 同样对于流数据管道pipeline订阅实时事件的组合使得可以将Kafka用于非常低延迟的管道但是可靠地存储数据的能力使得它可以将其用于必须保证传递的关键数据或与仅定期加载数据或长时间维护的离线系统集成在一起。流处理可以在数据到达时转换它。 有关Kafka提供的保证api和功能的更多信息可继续查阅本网 作者半兽人 链接http://orchome.com/5 来源OrcHome 著作权归作者所有。商业转载请联系作者获得授权非商业转载请注明出处。
