1。Kafka有什么优势1.多生产者可以无缝支持多个生产者，不管客户端使用的是单主题还是多主题。2、多消费者支持多个消费者从单独的消息流中读取数据，消费者之间互不影响。3、基于磁盘的数据存储支持消费者非实时读取消息，消息由于提交到磁盘，按照设定的规则进行保存。当消费者发生异常，消费者意外下线时，由于持久化的数据保证，上线后可以从上次中断的地方继续处理消息。4.可扩展性用户可以在开发阶段尝试使用单个broker，然后扩展到包含3个broker的小型开发集群，然后随着数据量的不断增长，部署到生产环境的集群可能包含数百个broker。5、高性能的Kafka可以轻松应对庞大的消息流，在处理大量数据时也可以保证亚秒级的消息延迟。二、Kafka的常见使用场景1、消息Kafka是传统消息系统更好的替代品。消息系统用于各种场景（解耦数据生产者、缓存未处理的消息等）。与大多数消息系统相比，Kafka具有更好的吞吐量，内置分区、副本和故障转移，有利于处理大规模消息。根据我们的经验，消息往往用于较低的吞吐量，但需要低端到端延迟，并且需要提供强大的持久性保证。Kafka在这方面与ActiveMQ或RabbitMQ等传统消息系统不相上下。2.网站活动追踪Kafka最初的使用场景是用户活动追踪。网站活动（网页浏览、搜索或其他用户操作信息）发布到不同的主题中心。这些消息可以实时处理，实时监控，也可以加载到Hadoop或离线处理数据仓库。3.指标kafka也常用于监控数据。分布式应用程序生成的统计数据的集中聚合。4.日志聚合许多人使用Kafka作为日志聚合解决方案的替代品。日志聚合通常从服务器收集物理日志文件并将它们放置在中央位置（可能是文件服务器或HDFS）进行处理。Kafka将文件的细节抽象出来，更清晰地将日志或事件数据抽象为消息流。这允许更低的延迟处理和更容易支持多个数据源和分布式数据消费。5.流处理Kafka中的消息处理一般包括多个阶段。原始输入数据从Kafka主题中消费，然后聚合、丰富或以其他方式处理成新的主题，例如推荐的新闻文章，文章的内容可以从“articles”主题中获取；然后对内容进行进一步处理，得到一个经过处理的新内容，最终推荐给用户。这种处理是基于单个主题的实时数据流。从0.10.0.0开始，轻量级但强大的流处理可以通过这种方式进行数据处理。除了KafkaStreams，还有ApacheStorm和ApacheSamza选项。6.事件收集事件收集是一种应用程序设计风格，其中状态变化按时间顺序记录。Kafka支持这种存储日志数据的非常大的场景。7.CommitlogKafka可以作为一个分布式的外部日志，可以帮助节点间复制数据，恢复作为故障节点的数据重新同步。Kafka的日志压缩功能很好地支持了这种用法。类似于ApachaBookKeeper项目。三、Kafka架构深入分析1、Kafka数据处理步骤1.1Producer生成消息，发送给处于Leader状态的Broker1.2Leader状态的Broker接收消息，写入对应的topic1.3Leader中的Broker收到消息后state以Follow状态发送给Broker作为副本备份1.4Consumer在Broker中消费消息2.Kafka核心组件2.1Producer：消息生产者，生成的消息会发送给一个topic2.2Consumer：消息消费者，消息的内容使用的消息来自主题2。3主题：消息根据主题分类。主题的本质是一个目录，即将相同主题的消息归类到同一个目录中。2.4Broker：每个kafka实例（或者说每个kafka服务器节点）都是一个broker，一个broker可以有多个topic2.5Zookeepers：Zookeeper集群不是Kafka的组件，但是Kafka依赖Zookeeper集群保存元信息，所以我在这里声明它的重要性。3.Broker和cluster一个独立的Kafka服务器称为broker。broker从生产者那里接收消息，为消息设置偏移量，并将消息提交到磁盘进行存储。broker为消费者提供服务，响应读取分区的请求，返回已经提交到磁盘的消息。根据具体的硬件及其性能特征，单个代理可以轻松地每秒处理数千个分区和数百万条消息。经纪人是集群的一部分。每个集群都有一个代理，它也充当集群控制器（从集群的活动成员中自动选出）。控制器负责管理工作，包括将分区分配给代理和监控代理。在集群中，分区从属于代理，称为分区领导者。一个分区可以分配多个broker，此时会发生分区复制。这种复制机制为分区提供了消息冗余，这样如果一个broker发生故障，其他broker可以接管领导。但是，所有关联的消费者和生产者都重新连接到新的领导者。4.消费者与话题的关系。Kafka只支持Topic。每个组可以有多个消费者，每个消费者属于一个消费者组；通常，一个群组会包含多个消费者，这不仅可以提高主题中信息的并发消费能力，还可以提高“容错性”。如果组中的某个消费者发生故障，则其消费的分区将自动由其他消费者接管。?对于Topic中的一条特定消息，它只会被订阅该Topic的每个组中的一个消费者消费，这条消息不会发送给一个组中的多个消费者；那么一个组内的所有消费者都会交错消费整个Topic，每个组内的消费者消息消费是相互独立的，我们可以把一个组看做一个“订阅者”。?在Kafka中，partition中的消息只会被group中的一个consumer消费（同时）；一个Topic中的每个分区只会被一个“订阅者”中的一个消费者消费，但一个消费者可以同时消费来自多个分区的消息。?Kafka的设计原则决定了对于一个topic，同一个group中不能有多个partition。多个消费者可以同时消费，否则就意味着部分消费者得不到消息，处于空闲状态。Kafka只能保证分区中的消息在被消费者消费时是有序的；实际上，从Topic的角度来看，当有多个partition时，消息仍然不是全局有序的。5.Kafka消息的分发?Producer客户端负责消息的分发?Kafka集群中的任何broker都可以向producer提供元数据信息，包括“集群中存活的服务器列表”、“分区领导者列表”等信息；?producer获取元数据信息后，producer会与Topic下的所有partitionleader保持socket连接；?消息通过套接字直接从生产者发送到代理，中间没有任何“路由层”。实际上，消息路由到哪个partition是由producerclient决定的，比如可以使用“random”、“key-hash”、“polling”等。?如果一个topic有多个partition，需要在producer端实现“消息均衡分发”。?在生产者端的配置文件中，开发者可以指定分区路由方式。?Producer消息发送的确认机制设置发送数据是否需要服务器反馈，有三个值0,1,-10：producer不会等待broker发送ack1：leader收到消息后发送ack2：当所有follower同步消息成功后发送ackrequest.required.acks=06。消费者负载均衡当消费者加入或离开一个组时，会触发分区均衡。平衡的最终目的是提高topic的并发消费能力。步骤如下：如果topic1，有如下分区：P0，P1，P2，P3加入到A组，有如下消费者：C0，C1首先按照分区索引号对分区进行排序：P0，P1、P2、P3根据consumer.id排序：C0、C1计算倍数：M=[P0,P1,P2,P3].size/[C0,C1].size，本例取值为M=2（向上舍入），然后依次分配分区：C0=[P0,P1],C1=[P2,P3]，即Ci=[P(iM),P((i+1)M-1)]如果本文对您有帮助，请关注点赞`，您的支持是我坚持创作的动力。转载请注明出处！
